Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: "XML Developers' List" <email@example.com>
- Date: Fri, 21 May 1999 06:30:57 -0400 (EDT)
Tim Bray writes:
> There's a new issue up over at XML.com which highlights an argument
> that's been going on here and there in private, but never
> heretofore in public: Is XSL a good idea? I'll be extremely
> interested in what the xml-dev community thinks.
As a process rather than a format, XSL starts at a severe disadvantage
-- the benefit of standardising a formatting/transformation language
(such as XSL[T] or DSSSL) is *much* lower than the benefit of
standardising a document markup language (such as XML or SGML),
especially as the quantity of documentation increases.
Here's a simple example: imagine a large company that maintains a
*lot* of documentation, say, 1M pages or more (such as a large
software company, and airplane manufacturer, etc.), and that spends a
lot of money and time manually editing and tweaking that documentation
for different outputs and processes.
The initial cost of setting up a big, automated XML or SGML production
system is high (perhaps many millions), but the benefit of
standardising is directly proportional to the amount of documentation
that exists: it will (roughly) bring twice the benefit for 2M pages as
that will for 1M pages. There is an enormous economy of scale here,
which can quickly offset the cost of setting up an XML or SGML system
in the first place.
Now, let's say that the same company is considering using XSL rather
than customized Perl scripts for generating output and for general
processing of those documents. 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.
Now, this example is
(1) document-centric rather than data-centric; and
(2) focussed on the production side rather than the client/browser
I'll leave it to others to discuss the client-side benefits.
All the best,
David Megginson firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)