XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition

Chapter 16. Extensibility

Previous chapters have discussed standard features of the XSLT language. This chapter discusses what happens when you need to stray beyond the XSLT 2.0 language specification. It's concerned with questions such as:

• What extensions are vendors allowed to provide?

• How much are implementations allowed to vary from each other?

• How can you write your own extensions?

• How can you write stylesheets that will run on more than one vendor's XSLT processor?

There is some interesting history here. XSLT 1.0 allowed stylesheets to call userwritten extension functions but provided no standard way of writing them. The draft XSLT 1.1 specification defined a general mechanism for creating extension functions written in any language and then defined detailed interfaces for Java and JavaScript (or ECMAScript, to give it its vendorneutral name). This specification was published as a working draft but was subsequently withdrawn. There were a number of reasons for this, one of which was simply that events were overtaken by the more ambitious XSLT 2.0 initiative. But part of the reason was that the proposals for standardizing extension function interfaces attracted heavy public criticism (see http://xml.coverpages.org/withdraw-xslScript.html). It's difficult in retrospect to summarize the arguments that were waged against the idea, but they probably fell into three categories: some people thought extension functions were a bad idea in principle and should not be encouraged, some people ...