Re: [xsl] functions and XSLT

[Jeni Tennison <mail at jenitennison dot com>]

Hi Dave,

As a first point - you should be looking at
http://www.jenitennison.com/xslt/exslt/common rather than the old URL
that you give for EXSLT.  Sorry - I should have put up some
redirection.

> 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!)

David C., Uche and I have been discussing this over the last week.

David C.'s position is that anyone should be allowed to add a function
to the repository, provided it comes with documentation and an
implementation and that the name has not already been taken. This
means that the repository can grow rapidly and with minimal red tape.
However, it means that any particular module (i.e. namespace) might
not be wholly implemented within a particular processor or by a
particular third-party implementation.

Uche's position is that the modules should be well-defined with
implementers told to implement everything in a module or nothing at
all. This means that authors can guarantee that certain functions will
be available within a particular implementation. The implication of
this is that the submission and discussion process has to be more
formal, with functions only accepted with version changes to EXSLT.

Yesterday, I suggested a complicated third way that would involve
having a core of peer-reviewed, tried and tested functions within each
module. Other functions could be added as per David's suggestion, so
that they're available quickly, but these would only be moved into the
core following review (on version changes).

I think that we don't want to make it too complicated - the point
about EXSLT is that it's *extensions* and it would be rather
depressing if XPath 2.0 incorporated all the extension functions we've
been talking about before we could standardise and implement them :)

> 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?

The reasoning is that templates cannot return node set values that
have not been freshly generated. It is not possible to author
set:intersection() [1] using a template. All you can get back
otherwise is a *copy* of the nodes in the intersection or a new node
set consisting of nodes that reference the nodes in the node set.  It
is also not possible to author functions that return boolean values
(e.g. set:has-same-node() [2]) using a template as templates return
result tree fragments, which are always boolean true.

Since functions that return boolean values or node sets containing
existing nodes are fairly useful, there's not a lot of point in having
constructs for user-defined functions that don't allow you to do so.
EXSLT uses exsl:result. Alexey's lambda expressions use 'xsl:return'.
David Rosenborg's FXPath [3] has functions containing a string that is
interpreted as (extended) XPath and evaluated.

The reason that xsl:template is not used for any of these is because
the functionality and content of a function-defining element then
becomes very different from xsl:template.  I think that we all feel
that we shouldn't change the semantics or syntax of XSLT elements.

Cheers,

Jeni

[1] http://www.jenitennison.com/xslt/exslt/sets/#function-set:intersection
[2]
http://www.jenitennison.com/xslt/exslt/sets/#function-set:has-same-node
[3] http://www.pantor.com/fxpath

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list