[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: why split? [was RE: XSL intent survey]
> Exactly. > Right. > True, so basically we agree, it's just a case of how to manage the details... > And if it is, is it fair to > saddle the transformation language with a non-viable different need? If it was really saddle as in `place an extra burden on' then I would agree but I don't really see this is the case. What I'd hope to happen is that _some_ XSL processors go all the way and produce some formatted output, others might work as xt does now which is to do the transforms but if you transform to formatting object it outputs the XML tree representing same, rather than actually rendering anything. > Sorry, I don't see TeX as a transformation language. Merely being able to > place an "if" in a language does not make it transformational. Of course, it is what you put in the `if' that makes all the difference:-) > Take for example the TexInfo system. It takes TexInfo files, and > transforms them into either TeX for printing or into Info for interactive > browsing. But the structure of the two is essentially the same. My point is that in a combined language you can for example re-order elements based on their typeset size, so if you get a whole load of figures or footnotes or whatever and they turn out to be small then you may choose to typeset them inline in some way rather than displaying each one full width. If you make a decision like that then you are writing a completely different formating object tree. However the _input_ to the decision process is the size of _trial_ typesetting of the constituent elements. This is the way you work in TeX all the time. It's not the way you code most tex documents, but someone (perhaps me) codes up these kinds of decisions which are then used in the formats like latex that typeset document instances. XSL being essentially _not_ a programming language is never going to work quite that way, however it is possible to imagine that certain set of such decision processes could be codified into an XSL construct of some form that did give a representation which allowed querying the result of the formatting in a way that allowed the transformation to reject certain possibilities and transform to a `good' typeset layout. So to some up I would say that if the two were split then: those needing just the transformational part would be in the same position, with the exception that the systems they are using would describe themselves as being XTL rather than `transformation-XSL'. Those only needing direct formatting with no transformation at all would probably use CSS-n. Those needing `moderately complicated' stylesheets would have to split the work between a transformation phase by a transfromation language producing something to be reparsed and formatted by a separate formatting language. Those needing `complicated' style sheets would be stuck. Unless someone implemented a language with a possibility of tight coupling between formatting and transformation. If this last language could in fact be used as the transformation language by the first two groups of people then there would be no need for having all these separate languages. (This might be a big if, but if this fails and you are _forced_ to split then so be it, but don't _aim_ to split as an ideal outcome). I can't see the gain in the split for any of the above groups, but probably it is a biased categorisation...) 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
|