What a great thread. I've got one observation (speaking obviously as a potential user of XSL, or whatever it turns out to be, rather than an actual implementor), and one "middle way" proposal. Observation: A couple of months ago, in clearing up one of the (then) confusions about XSL, James pointed out that XSL's style mechanism is intended to operate on the result tree, rather than the source tree, coming out of XSL's transformation mechanism. That seemed clean to me. Still, I wonder if what's being discussed now isn't a recasting of that original question: Cleaving the two would enable the style component to process *any* well-formed tree, no? Wouldn't that enhance the appeal of the style component? Proposal: Someone else on this thread has mentioned the importance of calling things by their right names. This gets at what is meant by "style" -- the "S" in XSL. That used to trip me up all the time, until it became clear (sometime last summer) that the word "style," despite its common everyday use, really means *behavior*: transformation+formatting. So: Would it help resolve the conflicting issues of both the "Split it!" proponents and the "Don't delay it!" proponents (and incidentally, those bound to abide by the WG's charter) to simply call Section 2 "XSL-T" and Section 3 "XSL-F"? I know you're all in this much more deeply than I am, and that I'm probably overlooking enormous subtleties (if that's not a contradiction in terms). Just thought I'd throw it in and return to the bleachers. Best, JES ==================== John E. Simpson Just XML (ISBN 0-13-943417-8) Available now from Prentice Hall PTR 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