Panning for EXSLT List Gold

Revision History
Revision 0.22006-02-01

Modify the suggestion for controlling indenting to ensure that we don't alter predefined XSLT semantics.

Revision 0.12006-01-31

Initial draft.

Table of Contents

(Long-)pending ideas

EXSLT is the independent effort to specify and organize support for extensions to the XSL family of W3C specifications. EXSLT currently includes XPath 1.0 extension functions and XSLT 1.0 extension elements. Most EXSLT activity takes place on the EXSLT mailing list; this list was primarily active through 2003; not many people engage the list anymore, but several users, including myself, are interested in renewing EXSLT development. This document attempts to summarize the state of EXSLT, first by listing outstanding issues and then by discussing other aspects of the EXSLT environment.

EXSLT currently provides 71 extension functions and 5 extension elements categorized into 9 modules. This set covers a significant set of desired functionality that was discovered after XSLT and XPath 1.0 were published. There is no formal versioning performed on the set of extensions as a whole, although there is some push from the community to do so. While this set is largely stable, the community does not have a good sense for where or how to draw a line and call something "EXSLT 1.0". This is one of the primary issues that EXSLT currently faces. A number of XSLT processors support a significant subset of EXSLT; this document does not (currently) attempt to track various implementations' EXSLT conformance.

This section catalogs a number of ideas and other requests that have come up on the EXSLT mailing list, but which have not been addressed properly by the community. Contact me or the EXSLT mailing list with any feedback on this list.

dyn:vars (March, 2001)

EXSLT currently has a module dedicated to dynamic programming concepts. At the time it was proposed, way back in 2001, Jeni also brought up the idea of a dynamic function which would return the names of all the current variables in scope. Did this just get overlooked? With respect to the dynamic programming module in the large, can we have a discussion about whether or not it is complete (from one perspective) or useful/used at all (from another)? Are there potentially other things that might be useful in the dynamic module?

Various interesting potential extension directions (March, 2001)

EXSLT currently only includes extension functions and elements, but there's no reason why there couldn't be other types of extensions as well. Much more recently, I had a conversation with Jeremy Kloth in #4Suite where he considered adding an extension attribute to the xsl:output element that would allow users to turn off indenting for selected elements (and their descendants) in a manner similar to cdata-section-elements. Perhaps one might call it exslt:no-indent-elements. After further discussion with Uche, we would also need a new output type so as not to (illegally) modify predefined XSLT semantics. Uche's suggestion: method="exsl:controlled-indent-xml". I know that several people have also expressed interest in a method="exsl:xhtml".

I think any effort in this direction would be solidly in the realm of a "next EXSLT version", though.

Won't fail document function; related functions (August, 2001)

It would be great if there were a variation on the document function that would not terminate the script on failure, as the built-in version is allowed to do. I'd love to see some motion on this, and I have some (potentially inane) ideas on this front.

baseURI and documentURI (January, 2002)

These are extremely obvious (at least to me), and I'd like to get them in. There is a current 4Suite extension providing this functionality, and I love having it. We probably want more URI management functionality as well. XPath 2.0 provides a number of functions with this support, and I think it would be a good idea to align ourselves with their work in this area.

EXSLT URI [Encoding] function proposals (August, 2003)

I think most of these were incorporated into the current specification, but I didn't see explicit confirmation of this. Can anyone confirm that our current functions provide the functionality discussed in this thread?

Interaction between node-set() and key() (December, 2003)

Keys should apply to the "anonymous" documents created by the node-set function. Did this concept ever make it into the specification?

Items requiring action (e.g. patches to be applied)
Needs more discussion or explicit confirmation
System properties/environment variables (December, 2004)

This idea seemed to get a lot of positive support, but never seemed to actually make it into the specifications.