Questioning XSL

[Charles Reitzel]

From: David Megginson <david at megginson.com>
>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 at megginson.com>
>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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)