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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Style vs. transformation, G. Ken Holman | Thread | RE: Style vs. transformation, Rob McDougall |
Re: Style vs. transformation, Paul Prescod | Date | RE: Style vs. transformation, Rob McDougall |
Month |