Re: Style vs. transformation

[Paul Prescod <papresco@xxxxxxxxxxxxxxxx>]

Rob McDougall wrote:
> 
> Wait a sec here.  XSL is an XML "meta-tool".  It works on any XML
> dialect.  Wouldn't you foresee other tools that also work on any XML
> dialect?  Does each of these tools also need to implement its own
> transformation capability?  I would hope not.

XSL is a stylesheet language. I have no problem with having a
standardized transformation language, and if you want to invent one, go
ahead. James Clark has already done so twice, and as Richard Light
pointed out, you can get a transformation language out of DSSSL just by
changing the flow object names.

But I see no reason to require XSL implementors to implement independent
transformation and style application steps. It complicates things, to no
real benefit. The problem that started this conversation is a single
case that rarely arises. It can be solved within the existing framework
(I've done so in the past, and so have others). It could also be made
easier to solve with a small extension to XSL. A transformation language
would be overkill, just as it for DSSSL style processing.

> You say that "style language is already essentially a transformation".
> I disagree.  

The style language is demonstrably a transformation. It takes input and
transforms it into output. It is also demonstrably a *complete*
transformation: any transformation that can be expressed in any other
transformation language can be expressed in the style language. It is
also a *good* transformation language. For SGML->SGML transformations, I
use the DSSSL style language variant available in Jade over any other
transformation language. Thus, in my opinion, an extra transformation
step will only rarely be useful, and will most often cause more problems
than it solves. I don't even want to consider the effort required to
create a wordprocessor that has an efficient implementation of a
two-step style sheet process.

> There are two separate mechanisms going on here.  The first
> mechanism transforms the tree structure of the incoming document to
> something that matches the desired output.  The second mechanism
> attaches style-related semantics to the newly structured tree.  The
> first mechanism is one that would prove generally useful to a large
> variety of tools that operate on XML.  The second is only useful in the
> context it's intended for (creating output).

Both the conversion from transformation tree to flow object tree and the
application of formatting semantics to the flow object tree are
transformations. If you separate them, you will be creating *two
transformation languages*: one from SGML to SGML, and one from SGML to
rendition. My understanding of DSSSL's history is that this was the
original plan: it was to have a structural transformation language and
then a simple style application transformation language. But it turned
out that there was no need to separate the two steps. The style language
was sufficient.

See: http://www.jclark.com/dsssl/bcs/transfrm.htm

So obviously you can do enough in the second transformation so that the
first is trivial (the identity transform). Now if you do enough work in
the first transformation, then the second one becomes trivial. Either
way you can easily make either part of the job so trivial as to be not
required. Since this works fine, I think the burden of proof is on those
who want to add another step. What's wrong with the situation as it
stands.

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

[Woody Allen on Hollywood in "Annie Hall"]
Annie: "It's so clean down here."
Woody: "That's because they don't throw their garbage away. They make 
        it into television shows."


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list