[Fwd: Re: Why XSL?]

[Paul Prescod]

-------- Original Message --------
Subject: Re: Why transformation?
Date: Wed, 30 Sep 1998 14:43:50 -0500
From: Paul Prescod <papresco at technologist.com>
To: xsl-list at mulberrytech.com
References: <199809301757.NAA29160 at hesketh.com>

BTW, I liked your Chicago Tribune article.

"Simon St.Laurent" wrote:
> 
>...
> Is there a good reason for this, or is it just that XSL has transformations
> because DSSSL did?  There must be something more to it than the comfort
> level of those used to working with SGML tools, but so far, I haven't heard
> much exciting.

Your question begs another: "Why did DSSSL have transformations?" FOSI's,
which preceded DSSSL did not. But they were found to be inadequate. In
fact, almost every SGML user has wrestled with a series of style languages
that do not do transformations.

> Where does XSL fit in an XML application architecture?

I discussed this in a talk on XSL recently. Slides are at
http://www.prescod.net/xsl/slides/17.html . The fundamental point is that
you cannot predict how your data will be used in the future, so you cannot
decide on the "optimal" encoding for it. Even if you knew exactly how it
was going to be used, the needs of document renditions and data storage
are often different. 

In a rendition, redundancy is your friend. In document maintenance, it is
your enemy. Actually, redundancy is probably the most important point.
Often you want to get rid of redundant markup ("Why should I always wrap
this series of elements when the wrapper can be logically implied?").
Often you want to get rid of redundant text ("Why should I type titles for
these columns, when I use the same column titles for every table of this
type?") Sometimes you want to get rid of completely redundant elements:
("Why should I the chapter title both in the document, and in the table of
contents, and in a dozen cross references")?

In a rendition, data should often be sorted according to some rule that
will help human navigation. In your document database, you probably want
to allow authors to enter it in any order. You may even need to sort the
same data according to different rules according to the rendering.

Transformations are the basis of all XML processing. I expect that within
a few years all XML-processing applications will have transformation
engines built in. Style application are just the start.

> Why is this more more useful than CSS?

Apples and oranges. CSS is a logical choice for the output of an XSL
transformation application. See http://www.w3.org/TR/NOTE-XSL-and-CSS .
XSL and CSS are only competitors in-so-far as XSL has its own formatting
model based on, but not identical to, CSS's. Presumably people who have
looked at the issue more closely than I have decided that CSS's formatting
model was not sufficient.

> What is the value of conflating style and transformation?

The XSL spec. does not conflate style and transformation. They are in the
same physical document, and are both called "XSL", but have separate URLs,
editors and processing models. If you are saying that even the names and
physical documents should be separate, then I agree that that would seem
simpler (except perhaps for the political/bureaucratic implications).

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.

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/
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)