RE: Questioning XSL
From: David Megginson <david@m...> >There can still, of course, be >benefits to standardizing (especially if there are OTS software >components available), but those benefits are proportional only to the >number of existing scripts or document types -- XSL will bring exactly >the same benefit for 1,000 pages as it will for 1,000,000 pages, >assuming the same number of processes and document types. The same argument applies, of course, to XML, SGML, TCP/IP or any standard. The need for standards is inversely proportional to the scale of the job. Very large jobs are rarely implementable using pure standards. If interoperability is required a standards compliant runtime interface is provided. An example would be an LDAP interface for Novell NDS. Novell, btw, recently tested a directory containing a *billion* user entries. I imagine the same kind of thing happening in the document space. Builders of large document repositories will do what they have to do to get the system to run. They may then use a DSSSL/XSL layer to export SGML, XML, MS Word, HTML, etc. (Forgive me if I'm misrepresenting DSSSL capabilities). So I think XSL will be much more important to the 1,000 page users. As you point out, they have a much smaller potential return and, therefore, a proportionally smaller document repository software budget. This is good news. The very large sites have had repositories for years. There are many, many more small to medium scale sites. The XSL standard should really be targeted at the OTS software vendors supporting this user base. As always, design for the norm, allow the odd case. The same thinking applies to most "Internet" software. The fact is, large companies have been on-line to each other for years. It is the small to medium scale operations that are starting to leverage the public network. Personally, I think this is a fascinating phenomenon of no small economic importantance. Simplifying and clarifying XML/XSL could help this process along. Later in the thread: David Megginson <david@m...> >1. XSL will be easier to maintain because it is mostly declarative > rather than procedural, and there is less room for obfuscation > (please don't take that as a dare, though). This is a tough question. In the SQL space I learned over time when to lean on the declarative power of SQL and when to avoid it. Some things are just more procedural in nature, others declarative. The trick is knowing how to combine procedural and declarative logic for the problem at hand. The database industry has come full circle on this topic and now Java w/ embedded SQL is becoming the database stored-procedure language of choice. Same issue, different context. For XSL, strong declarative capabilities will take you far (especially if the syntax isn't too obscure). If you need to do something procedural, and you will, I imagine you would break up the problem into multiple, small, efficient XSL queries and piece the resulting parts together with Java (via SAX extensions for XSL, of course). Best regards, Charles Reitzel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format