functions and XSLT
Just some ruminations of mine... I. Implementation of functions in XSLT: issue for XSLT 1.1 or 2.0? Some people have expressed a strong preference for the ability to write functions in XSLT be available for XSLT 1.1. I think this is unrealistic. XSLT 1.1 is intended to make incremental improvements to XSLT 1.0; XSLT 2.0 is intended to include major new functionality. It's important that such an issue be given much discussion before being recommended by W3C, because any modifications that were insufficiently thought through before publication as XSLT 1.1 would be extremely difficult to remove later. II. common extension function collections I'm quite pleased to see work such as that found in appendix B of http://www.jenitennison.com/xslt/exsl.html. Common libraries created by the user community will no doubt be of much use in the future. The appropriate level of formality / informality that should be involved is an issue that I feel has been neglected, though. The intent seems to be more than to simply provide a web repository of contributed code, but how much more is entirely unclear to me. The C++ library group Boost.org (http://www.boost.org) has a formal submission process, including peer code-review. Perhaps that's too rigid? I don't have a good feel for what others are expecting. For myself, I can say that if I'm going to use exsl library code, I'll be examining it myself thoroughly unless I can be confident that a couple of people other than the code's author already have. (Not that this would be a bad thing to do in any case!) III. extension function authoring in XSLT This is, in my opinion, the most contentious issue. exsl:function (again, http://www.jenitennison.com/xslt/exsl.html) seems to have picked up quite a bit of support early, yet I can't help but feel that it's not the right way to go about this. The concept of subroutine is expressed in XSLT by the template. Templates take parameters; templates define scope; templates encapsulate algorithms; templates compute returned results. So why is it that proposals to extend XSLT to allow the creation of functions written in XSLT go to the trouble of inventing a new syntax to define them? I've been asking myself "what is so different between a named template and this exsl:function?" I haven't come up with a good answer, so now I'm asking you. Is there a difference in accessibility from XPath expressions? No, it would be just as easy to reference a named template from an XPath expression as it would be to reference an exsl:function, if the XPath spec allowed this sort of thing. Is there a difference in accessibility of source-tree-fragment nodes? No, the definition of "exsl:function" doesn't imply that nodes being returned are from the source tree. Is there a difference in the expressive power of a named template and an exsl:function? No, any differences in expressive power exist due to other proposed exsl: elements. In particular, judicious use of xsl:variable can make things that might otherwise seem troublesome easy. It seems to me that exsl:function is redundant -- and given the choice, I'd rather not have XSLT end up looking like ADA95. Late addition: I'm intrigued by Alexey Gokhberg's proposal for first-order functions (lambda expressions). Oddly enough, he also suggests <xsl:define> (aka exsl:function!) instead of relying upon the normal template mechanism. Argh! What am I missing!?!? :-) Dave Gomboc 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