Re: Style vs. transformation
Rob McDougall wrote: > > Wait a sec here. XSL is an XML "meta-tool". It works on any XML > dialect. Wouldn't you foresee other tools that also work on any XML > dialect? Does each of these tools also need to implement its own > transformation capability? I would hope not. XSL is a stylesheet language. I have no problem with having a standardized transformation language, and if you want to invent one, go ahead. James Clark has already done so twice, and as Richard Light pointed out, you can get a transformation language out of DSSSL just by changing the flow object names. But I see no reason to require XSL implementors to implement independent transformation and style application steps. It complicates things, to no real benefit. The problem that started this conversation is a single case that rarely arises. It can be solved within the existing framework (I've done so in the past, and so have others). It could also be made easier to solve with a small extension to XSL. A transformation language would be overkill, just as it for DSSSL style processing. > You say that "style language is already essentially a transformation". > I disagree. 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. Thus, in my opinion, an extra transformation step will only rarely be useful, and will most often cause more problems than it solves. I don't even want to consider the effort required to create a wordprocessor that has an efficient implementation of a two-step style sheet process. > There are two separate mechanisms going on here. The first > mechanism transforms the tree structure of the incoming document to > something that matches the desired output. The second mechanism > attaches style-related semantics to the newly structured tree. The > first mechanism is one that would prove generally useful to a large > variety of tools that operate on XML. The second is only useful in the > context it's intended for (creating output). Both the conversion from transformation tree to flow object tree and the application of formatting semantics to the flow object tree are transformations. If you separate them, you will be creating *two transformation languages*: one from SGML to SGML, and one from SGML to rendition. 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 So obviously you can do enough in the second transformation so that the first is trivial (the identity transform). Now if you do enough work in the first transformation, then the second one becomes trivial. Either way you can easily make either part of the job so trivial as to be not required. Since this works fine, I think the burden of proof is on those who want to add another step. What's wrong with the situation as it stands. 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format