Re: XSL & XLL
At 11:12 1998 03 11 -0500, Rob McDougall wrote: >Recently, when I was examining the XSL spec and the XLL spec, it >occurred to me that the purpose of XLL is very similar to the purpose of >patterns in XSL. Both are used for identifying one or more target >elements in the destination document. They share a lot of common >functionality for locating the target elements. Why then, are the two >syntaxes so different? > >The only differences (that I can think of) between the two are: >- heritage (one is based on DSSSL, the other on HyTime) >- typical use case (one tends to target all instances of a particular >element, while the other tends to target a specific instance of a >particular element) > >This last difference shouldn't be very significant, because I believe >that XLL must be able to let you link to all the instances of a >particular element in the target document, and XSL must let you target a >specific instance of an element in the target document. There is quite a bit of overlap in people on the XML and XSL WGs. The key reasons for differences between XPointer (the part of XLL that defines addressing) syntax and XSL pattern syntax are the user requirements, not heritage. And user requirements for XPointer and XSL patterns do differ. It may be reasonable to make sure that XPointer and XSL patterns share an underlying similarity of "object models" (and I use that term loosely, not in the DOM sense), but it is perfectly reasonable that they do not share syntaxes or have a 100% overlap in capabilities. Syntactically, XPointers need to fit into URL syntax and XSL patterns need to fit into XSL element/attribute syntax. An XSL pattern forms the "left hand side" of a rule in a set of rules, and there must be a comprehensible arbitration (specificity) algorithm to determine which rule gets used when; XPointers have no such constraint. This means that XSL patterns may omit some capabilities that make sense to have in XPointers. XSL is not an exercise in trying to cram all the cool stuff we can think of into one standard. On the contrary, we are trying to learn from XML (and the wide-spread-within-W3C reaction to the XML PR which was that it was still too complex) and keep as much as possible out of the standard while still addressing a reasonable set of user requirements and design goals. Speaking for myself, I will argue to keep XSL patterns relatively simple. Greater "selective power" may be allowed on the right hand side (the "action"), but even there we may not match XPointer capabilities 100%. 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