XSLT Extensions Revisited

Background

In March 2000 the Deviant summarized a debate that ranged over several mailing lists. Its subject was concerns about lack of portability of stylesheets among the major XSLT engines. While the XSLT specification defined a language-neutral extension mechanism for extension functions, implementors were tied to the proprietary APIs provided by a particular XSLT engine. This meant that functions, and hence stylesheets, were not portable. (See "Unifying XSLT Extensions" for additional background.)

At the time the consensus was that a standardized language binding was required, along with implementations of common extension functions. Shortly thereafter the XSL Working Group announced that it was aware of these concerns and was planning to address them in a revision of the XSLT specification.

Requirements for XSLT 1.1 was subsequently published, noting that the "primary goal of the XSLT 1.1 specification is to improve stylesheet portability." The culmination of several months of work was the publication of the first Working Draft of XSLT 1.1.

Scripting Considered Harmful

How does XSLT 1.1 address stylesheet portability? In addition to a detailed list of requirements are available, recent discussion on the XSL mailing list has highlighted two aspects in particular.

to their specification...We specifically followed the DOM and SVG Working Group's lead on this area.

Noting that for true portability the use of extension functions should be avoided, Muench observed that the situation is improved in XSLT 1.1 as extension functions themselves are more portable due to the common language bindings.

In XSLT 1.0, developers who today extend XSLT with extension functions in ECMAScript using Alexey's Unicorn processor cannot run them with Microsoft's MSXSL3 processor. They both support ECMAScript extensions, but they do it in incompatible ways.

If both Microsoft and Unicorn produce conformant XSLT 1.1 processors, then these stylesheets with ECMAScript extensions would run interchangeably on both.

Attempting a common binding involves a trade-off: defining a portable IDL API means that particular features of specific target languages cannot be leveraged. For example the DOM has been declared less than ideal because it doesn't make use of some Java API features, hastening the development of JDOM. Mike Kay gave little credence to claims that defining XSLT language bindings was detrimental to portability.

How can defining a Java language binding, which implementors are at liberty to implement or not, reduce interoperability when compared with allowing each implementor to invent a different Java language binding, which is the current situation at XSLT 1.0?

The introduction of the <xsl:script> element, which allows scripting code to be embedded in a stylesheet, has been much more controversial. Interestingly an early draft of the XSL 1.0 specification included an almost identical facility (<xsl:functions>). It was added to the 21st April 1999 revision but removed in the next draft (9th July 1999). Since no explanation was given it's not clear why the decision to remove it was reached. A similar mechanims is already heavily used Microsoft XSL environments.

Uche Ogbuji was particularly critical of this new feature.

In general, I think the re-introduction of xml:script is execrable. XSLT 1.0 had perhaps the most elegant extension model possible, and xsl:script ruins this by destroying the opacity of extensions to XSLT processors.

Ogbuji further claimed that inlining scripting code breaks XSLT 1.0's layered extension model.

The first problem I see with xsl:script is the human engineering aspect. XSLT 1.0 had extensions but had the admirable quality that extensions were opaque to XSLT itself. This encourages people using XSLT to have the XSLT mind-set and learn how to solve problems within the language. At some point they might come across a situation that needs extensions, but putting this in place was a separate operation with their stylesheet processor which set up an *environment* for the opaque extensions within XSLT itself. I think this healthy layering is a good part of the reason why there has been so much advancement of the state of XSLT practice in just one year: it was quite clear how to layer one's thinking between XSLT and extension. With xsl:script, the layers are muddied, and I think it will lead people (who, after all often search for expedient over good sense) to jump in with extensions without mind[ing] the inevitable interoperability problems.

Francis Norton, an advocate for writing extension functions in XSLT itself, also expressed dismay over the new model.

I invested a lot of time and effort into doing things the XSLT way, however quirky it might seem to the uninitiated, on the grounds that it was portable and it was the right thing. Now the message is that if we want to write extension functions, XSLT is the wrong thing. I'm starting to feel disillusioned.

Few contributors saw much utility in embedding script code, but particularly if the same end can be achieved using extension functions handled separately by the XSLT engine. Most were hostile towards the prospect of Java, Visual Basic, or C# code appearing within stylesheets. Yet the requirements document lists this as a desired feature.

Scott Boag observed that the requirement was added in response to user feedback. He invited the community to comment if this was no longer the case.

For one thing, it's not too late. The thing is in draft stage. All or most of the XSL WG members read this list, and do actually care about people's thoughts. I might remind you that the XSLT 1.1 extensions mechanism is in response, for a large part, to discussions on this list about how people really do need and want interoperable extensions, to the degree that such a thing is possible. If we have got it wrong, then we're listening. But so far you haven't convinced me with your arguments.

...If you really don't want this at all, then start a petition or something, and present it to the XSL WG or the W3C. But my impression is that the vast majority of users badly want some sort of interoperable extensions, without having to rewrite the extensions for each processor.

Boag hinted later that the Working Group is directing its energies towards XSLT 2.0. There is plenty of opportunity for change.

XSLT 1.1 is on hold for a bit while we get some architectural ramifications of the 2.0 design sorted out. If you do it based on 1.0, and the processor implementors band together in a way that the user community agrees on, believe me, we'll be *very* happy to do the deletions to the 1.1 draft. We didn't do this for the fun of it... it was from user requests... [T]he user community, i.e. the xsl-list, the Apache community, and our corporate customers, have asked for it. If you don't like the effort, make constructive suggestions, write a complete alternate proposal, or start an alternative effort.

Also, I believe the XSL WG would be very happy to put together some conference calls among XSLT implementors to sort out concerns about language independence in 1.1.

The issue is still unresolved, and the robust debate continues. Whether or not the concerns expressed are well-founded, the advantages of XSLT 1.1 should not be overlooked. The standardization of multiple output documents is one feature that will surely benefit many developers. It's also promising to see that the XSL Working Group is willing to respond openly, and in some cases at great length, to address community concerns.