Re: Style vs. transformation

>>If I implemented XSL with Python as its expression
language would I be cast into utter darkness...<<

No, but isn't XSL meant to be for the HTML crowd, 98% of whom know something
about Javascript, and 1% of whom know about Python?

My understanding is that XSL was implemented because DSSSL-0 was too
complicated for the average web author.
Frank

-----Original Message-----
From: Sean Mc Grath <digitome@xxxxxx>
To: xsl-list@xxxxxxxxxxxxxxxx <xsl-list@xxxxxxxxxxxxxxxx>
Date: Wednesday, March 04, 1998 3:43 AM
Subject: Re: Style vs. transformation


>[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
>


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