[xsl] functions and XSLT

["Dave Gomboc" <dave@xxxxxxxxxxxxxx>]

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