Re: why split? [was RE: XSL intent survey]
> Transforming to formatted output is merely one of many tranformations. Yes of course, agreed. > And, there are many ways to describe a formatted document -- TeXML among > them. > All I (and some others) are saying is that the two problems are distinct > enough that they are best solved separately. Which almost sounds reasonable put like that. (But I still don't agree:-) I think that the transformation language (or language part) needs to be as powerful as can be managed without offending the essentially declarative language design. So for applications that are not formatting anything there is no real disagreement. The only question is whether to split off the formatting objects into a separate language. Given that you have a transformation language, there is nothing to stop you have a target XML DTD that abstractly describes a formatted document and then you can transform to that. That I gather is what texml is (I plan to get it this week and look) and of course you could write any other formatting language in XML syntax followed by a simple translation to its native syntax. I see two problems with this approach. Firstly by targetting a specific language you lose (or at least have to work harder to regain) the cross system abilities of a system like dsssl or xsl. I can write far more expressive and powerful formatting requirements in tex than I can in dsssl; but if I do it in dsssl then I can produce the same document, with essentially the same style, produced from the same style sheet, in TeX or rtf for MSWord etc, or mif for framemaker. The second thing you lose by separating the two is adequate feedback between the style language and the transformation. Currently this is not there in XSL (and is weak in DSSSL implementatons like jade that have a clear break between the front end dsssl engine and the back end typesetter). However if the languages are separated there would be no chance of ever improving this. The main reason why TeX is more expressive as a style language is that the transformations can be controlled by the results (or potential results) of the typesetting. That is, you can say `if this caption would fit in the margin in under three lines, do that' else do something else (which may involve completely re-arranging the page makeup, so that it does all fit). If you have a model where the transformation is done first, and then you just run the result through a simple style language then you are never going to be able to express complicated page makup requirements. As you can not answer questions like the above without having direct access to the formatter. > Of course, non-trivial formatting tasks will require that you use both, but > they're still designed better in (relative) isolation. But the problem is that you need to use both interleaved at multiple points in each visual area. You can't do all the transformation then all the formatting in two simple steps. David 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