Re: Style vs. transformation

Richard Light wrote:
> 
> So yes, DSSSL _as_implemented_ just gives us the DSSSL style language,
> or more precisely, the DSSSL-O subset of the DSSSL style language.

Jade is more than DSSSL-O.

> This, I would argue, has very limited transformation abilities, which
> beings us back to the original point - how do we support reasonably
> complex transformations in XSL?  

The transformation abilities of the style language are complete: any
transformation that is possible can be specified. The question is how
easy is it, and how much code does it take. My impression of the DSSSL
transformation language is that it would allow advanced transformations
to be specified with very little code, but that it is harder to learn
than the style language.

> If we do have to invent something, then
> I am simply suggesting that we look to DSSSL-transform for ideas rather
> than starting from scratch.

I think that Jade's transformation back-end is a more appropriate guide.
That is essentially what you suggested when you spoke of running "XSL
twice". But I still don't think that we should require a separate level
of transformation when the style language is already essentially a
transformation.
 
> (Incidentally, I would see this issue as similar to the need to include
> XLL and XSL itself in the XML framework, even though its antecedent SGML
> doesn't have built-in linking and style support.  Sometimes the needs of
> the Web take us further than we went before ...)

HyTime and DSSSL are part of the SGML framework just as XLL and XSL are
part of the "XML framework".

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