Re: Style vs. transformation

Subject: Re: Style vs. transformation
From: Sean Mc Grath <digitome@xxxxxx>
Date: Wed, 4 Mar 1998 11:38:52 GMT
[Paul Prescod]
>
>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.

I have some in the trenches experience of this that lead me to
the conclusion that separate tree transformation and tree formatting
is more trouble than it is worth.

Executive Summary : I agree with Paul Prescod

Details:

In developing the IDM SGML transformation system,
we started out with the idea of developing DTDs to
encapsulate the capabilities of any rendered output format.
We created DTDs for Winhelp, Folio, Motes, RTF, MIF etc.

>From there, we reasoned, we had a straight tree transformation
task and no need for a style language. Fine in theory, horrible
in practice. The complexity of expressing the tree transformation
from say Docbook DTD to Winhelp DTD is just terrible.

So we introduced a style language. The style language allowed
us to say:
        NewParagaph()
        AddToLeftIndent ("512")
        BoldOn()
        AddText ("Hello World")

Behind the scences, this was just syntactic sugar for a tree
creation process. Then we had an epiphany - why not just say:-

        StartElement ("PARA")
        AddAttribute ("LeftIndent","512")
        AddAttribute ("Bold","1")
        AddDataNode ("Hello World")
        EndElement ("PARA")

The achieves the same effect but uses a Style Langauge as a general
purpose SGML -> SGML transformation. After three years of
interative development of this stuff we now have a style
language (Python) and a collection of DTDS.
To target Winhelp, we create flow objects from the Winhelp
DTD. A simple back-end conversion then converts from there
to native Winhelp RTF.

Most of the tree transformation code we wrote has
fallen into disuse as more and more gets achieved
in the style language.

In defense of a Tree Transformation approach, it does
lead to good problem decomposition and code reuse.
You break a complex transformation down into a collection
of intermediate stages (we called them deltas) and the 
entire transformation is achieved by "piping" them together
Unix style.

I would like to see something in XSL that supported
"chaining" the flow object tree resulting from one
stylesheet transformation into another stylesheet.

On a slightly related note, by far the biggest headache
we have to deal with in doing SGML/XML formatting is dealing
with document *collections*. We have found that our
style language invariable needs meta-data about the
document collection to generate the desired output.
This ranges from simple "next/previous document" metadata
for document chaining via hypertext through to running
headers for non-scrolling regions and so on.

Is there anything the works for XSL that would support
this sort of thing? Allowing a stylesheet access to
command line paramaters would be a good start.

Finally, finally. A curved ball. Is XSL inextricably
linked to JavaScript as it scripting environment?
If I implemented XSL with Python as its expression
language would I be cast into utter darkness...

Sean


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


Current Thread