Extensions to XSLT

The Beginnings

2001 is certainly turning into an eventful year for the XML community. The new year began with the community-led development of RDDL (see Old Ghosts: XML Namespaces), and the past month has seen a lot of heated debate over the future directions of many core W3C specifications, including XPath, XSLT, XML Schemas, and XML query (covered in the last few XML-Deviant columns).

These fires of debate were first lit by sparks flying on the XSL mailing list over the first Working Draft of XSLT 1.1. This debate has recently started bearing its own fruit. The community has discussed alternatives to the contentious <xsl:script> element. As regular readers will recall, the major concerns over xsl:script were that it would encourage scripting code, authored in Java, Javascript, VBScript and other languages, to be embedded inside XSLT stylesheets hampering usability and (potentially) interoperability.

The discussion lead to suggestions that XSLT extension functions might usefully be implemented in XSLT itself, rather than, or perhaps in parallel to, implementations in other languages. A number of ways of achieving this functionality were suggested, resulting in Jeni Tennison gathering together the alternatives to further focus the debate and achieve progress:

There seems to be a reasonable amount of support for user-defined functions written in XSLT, whether to sweeten the syntax of xsl:call-template or to allow XPaths previously only dreamed about.

If we're going to move ahead with this, we need to agree on a syntax for (1) declaring the functions and (2) calling the functions. In this email, I'm going to lay out the major designs that have been suggested so far so that we can discuss them and hopefully come up with some kind of resolution that's acceptable to everyone.

The collated design notes prompted a lengthy discussion, resulting in the eventual publication of the initial design document for Extensions to XSLT (EXSLT), which Jeni Tennison announced to the XSL mailing list:

The main part of the document specifies the extension elements and functions (viz exsl:function, exsl:return and exsl:node-set()) that we've been talking about. Several outstanding issues are highlighted, but comments on other areas are welcome. It would be particularly helpful to hear from implementers.

Appendix B gives loads of use cases of functions that could be implemented under this scheme, many of them borrowed from Saxon, which demonstrate the strengths (and weaknesses) of the scheme described in the document. If you have more use cases, then please let us know about them and, preferably, their solution.

What is EXSLT?

Following feedback on the initial draft, Tennison has refined the EXSLT proposal to add further detail and split the specification into four modules:

• EXSLT - Functions defining several extension elements that can be applied to writing extension functions in XSLT
• EXSLT - Common which defines a set of commonly useful XSLT functions
• EXSLT - Math defining a number of mathematical functions, e.g. min, max
• EXSLT - Set which specifies functions for set operations, e.g. intersection

All extension elements and functions defined by EXSLT modules belong to the root namespace http://xmlns.opentechnology.org/xslt-extensions/ which was donated for this purpose by Uche Ogbuji. Ogbuji has also defined RDDL directories for each of the EXSLT namespaces, and he has already provided support in 4XSLT for the common, math, and set functions.

The EXSLT drafts also include the notion of conformance, noting that

XSLT processors are free to support any number of the extension elements and functions described in this document. However, an XSLT processor must not claim to support "EXSLT module name" unless all the extensions described within this document are implemented by the processor.

The EXSLT functions have been compiled as the result of the community discussion orchestrated by Jeni Tennison following the model used for several XML-DEV projects. EXSLT is therefore the beginning of a standard extension library for XSLT stylesheets.

However EXSLT isn't the only proposal on the table. David Rosenborg has produced a parallel proposal called FXPath or Functional XPath. In his announcement, Rosenborg contrasted the two approaches.

The purpose of this document is to outline an alternative approach to writing extension functions in XSLT. The FXPath approach is based on XPath where as EXSL is based on XSLT instructions. The basic idea is that functions dealing with primitive XPath types are better implemented in a language close to XPath rather than by retrofitted XSLT instructions.

Rosenborg has developed his proposal and provided a SAXON implementation to allow users to experiment further. Jenni Tennison, in welcoming the proposal, commented that it raised questions about the current capabilities of XPath and XSLT.

I think it raises philosophical questions about the balance between XSLT and XPath. One of the aims of XSLT was that it be written in XML -- that it should use elements and attributes for its programming constructs. But if *everything* was in XML... well there'd be *even more* objection to XSLT's verbosity! So some of it was moved into a more compact, non-XML syntax -- XPath.

Now I don't think that the line was drawn at the right place: there are some things that are only possible to express in XSLT that I think should be expressible using XPath, notably conditional expressions.

The Advantages of EXSLT

What are EXSLT's advantages given that XSLT already provides an user extension mechanism?

First, it ensures that the extension functions are well defined in a community-drafted specification, avoiding the need for XSLT developers to rely on proprietary definitions of similar functions provided by their stylesheet engine. Also, while the implementation language for a function may vary, developers can ensure that functions will remain consistent across processors. The current situation, in which developers are tied to a specific XSLT implementation, is reminiscent of the situation that arose when browser vendors added proprietary elements to HTML. The intent is different but the results largely the same: portability and interoperability suffer.

Second, by providing the means to define their own functions in XSLT, stylesheet authors can create truly portable stylesheets that rely only on a conformant XSLT 1.0 processor that implements the elements defined in EXSLT - Functions. As well as allowing the development of functions in a language with which they are already familiar, authors are no longer entirely reliant on implementations provided by a particular XSLT engine, something which has been a concern since March of 2000..

Next Steps in the Process

For the EXSLT function library to continue to grow it should be possible for anyone in the community to propose new functions. David Carlisle suggested that the library be organized similarly to CPAN.

I'd like the extension namespace to basically allow suggestions for new functionality on a more or less first come first served basis. There shouldn't be any pressure for anyone to implement it all (if it only contains two functions, there will be pressure, if it contains 2000 probably not). Compare CTAN (or its better known younger sibling, CPAN) if the name doesn't clash with something there, then it gets added. (You'd want a bit more moderation for this, but not much).

I don't really care (so much) which functions are in the list. What I care about is that if two implementers are implementing the same function, they should have an _easy_ way to get that function added to the exslt namespace master list, so they can each implement it in that namespace and users can use the function without caring which processor implementation is being used.

The creation of a standard library should also feed into the W3C's future development of XSLT -- a process which, to some extent, is already taking place. The main goal of XSLT 1.1 is to standardize extended features common to many XSLT engines. It's likely that the EXSLT library of extension elements and functions will fulfill the same role, allowing for earlier standardization of those features. Jeni Tennison shared her view of the standardization roadmap.

I see the route being:

 user-defined extension functions (in XSLT or other
  languages) -> community standardization -> W3C
  standardization

In other words I think that the definition of extension functions by users will help the community to see what functions are useful and give a good starting point for their standardization. If anything, I think that user-defined extension functions will lead to quicker adoption and more robust definition of those standards.

A deciding factor in the success of EXSLT will be whether it's supported by XSLT engines. The prospects are promising, particularly as 4XSLT has already adopted the proposed functions. If the developers of Xalan and other stylesheet engines adopt it, then the future looks decidedly rosy for XSLT developers.

Thanks to Jeni Tennison for contributing to this article.