Re: Style vs. Transformation

[Jacques Deseyne <jdeseyne@xxxxxxxxx>]

Paul Prescod wrote:

>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

I understand the wording of this slide as that originally, the transformation
language was needed also for _formatting_ tasks, but that the style language
can now handle that (formatting) by itself. The Transformation Language
itself was kept independently in DSSSL because of its usefulness.

At SGML Europe '97, Anders Berglund gave me the example of a table
columns-first markup scheme which would definitely need a transformation
to be used with a style specification for a rows-first table markup approach.

>The style language is
> [...] 
>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.
> [...]

Has this been demonstrated somewhere ?  I'd be interested in any pointers.

>But I see no reason to require XSL implementors to implement independent
>transformation and style application steps.

Probably, an independent transformation step seems overkill in a _Style_ 
language. But why couldn't you expect requirements for modifying the document's
structure during processing ? Do you really believe that the frequent transformation 
needs among SGML users (evolution of DTDs, authoring vs. repository DTDs, ...)
will all of a sudden disappear because they're using a fixed concrete syntax ?

IMHO, Richard is right to point to the DSSSL transformation approach. It is an
extremely powerful model but may be too sophisticated.
Another starting-point could be a look at existing transformation tools from different 
coordinate systems (event-driven vs. markup-driven vs. tree-driven; declarative vs. procedural,
etc.). 
Yet another potentially interesting approach could be to pick up SGML's ever-ignored 
explicit link feature, which is far too limited in ISO 8879, I agree, but of which
the simple declarative style has some benefits against DSSSL's transformation
statements.

All the best,

--
Jacques Deseyne <jdeseyne@xxxxxxxxx>


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