Re: why split? [was RE: XSL intent survey]
David Carlisle <davidc@xxxxxxxxx> Wrote: >so basically we agree, it's just a case of how to manage the details... God (and the Devil) are in 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. Try it the other way - is it fair to saddle a formatting language with an unrelated need, that of being a complete transformation language? Let us recall that this whole thread started since requests for certain transformation features were rejected (well, at least discouraged) on the grounds that XSL is intended to be a stylesheet language and not a complete transformation language. If XSL was intended to be both we wouldn't be having this problem. Personally I think that is too much to stuff into a single language. >> 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. Well... There are structural transformations involved. Whether they are "essential" is something very slippery to define. At any rate, an example of a system which doesn't require feedback doesn't prove feedback isn't sometimes necessary; I just wanted to give a sample of how far you can go without such feedback - very far providing the target language is strong enough. >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. I have no problem with a formatting language containing high-level instructions to the formatting engine. Formatting tags which include alternatives for various conditions (e.g. sufficient place on the page), or giving the engine leeway in positioning elements (e.g. floating figures) are good examples. Some things would admittedly be impossible - say, ordering a list based on the width of the text in each entry. I'd like to see a concrete example of a _useful_ transformation which would become impossible. I suspect that such features are not in demand. To justify this feeling I can say that I haven't seen requests to extend XSL in this direction. On the other hand, I've seen several pleas to keep XSL simple, when requests to add complex transformation features were submitted. >... 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. I agree, except I'd use "format" instead of "transform". But that's exactly the issue, isn't it :-) >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'. And they would be able to add modes, and scripting, and local variables, and whatever, without having the formatting people complain that "it is too complex" and "this isn't in the intent". It also would become possible to have a standard XTL processor without having to add "without the formatting semantics" (standard conformance is important!). >Those only needing direct formatting with no transformation at all >would probably use CSS-n. They already do :-) If XFL would be simple they'd have the incentive to switch to it and if it were easy to implement (as in no complex transformations), browsers would correctly implement it giving them the opportunity to do so. >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. Allowing them do cleanly separate concens (why does collecting the table of contents, or reordering products by price, have to be intermixed with choices on which font to use?). I could also make the claim that separation of computation locations also makes sense here - if all you want to see is the TOC, it doesn't make sense to send you whole book over the internet and then have your XSL extract it on the client, does it? >Those needing `complicated' style sheets would be stuck. Unless someone >implemented a language with a possibility of tight coupling between >formatting and transformation. As I said I'd like to see some real-world examples of things you can't do with separate transformation and formatting passes - given that the formatting language allows you to respond to formatting queries in a reasonable manner. >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). This "if" depends on how complex you allow XSL to become. I think that the KISS approach to the formatting language is important. A language doing both general transformations _and_ formatting would be anything but simple. >I can't see the gain in the split for any of the above groups, >but probably it is a biased categorisation...) Well, I think I pointed out advantages to the first three, which I feel cover most of the users/applications/needs. As for the last group all I can say that in general it isn't worth bending systems out of shape to satisfy the extreme cases. This is also probably a biased opinion - though I've been working on "extreme cases" several times myself :-) Share & Enjoy, Oren Ben-Kiki 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