Saxon extensions to the W3C XSLT/XQuery specifications

Changes to existing Saxon extensions and new extensions in Saxon 11 are outlined below. This includes extension functions and instructions in the saxon namespace, as well as experimental implementations for version 4.0 extensions to XPath, XSLT, and XQuery. A W3C Community Group is working on these proposals; for more information see the QT4CG Specifications, and documentation about the Saxon implementations at Experimental 4.0 extensions.

Changes to Extension Functions

Many of the extension functions in the saxon namespace have been re-implemented as integrated extension functions where they were previously reflexive extension functions.

The main impact is that these functions now enforce the specification more strictly. In particular, the function name must be spelled as specified; it is no longer possible to use alternative spellings such as saxon:printStack for saxon:print-stack, or saxon:stringToBase64Binary for saxon:string-to-base64Binary. The functions may also be stricter about what types of arguments they accept.

Another effect of the change is that calls on these functions can no longer be customized by use of a user-written JavaExtensionFunctionFactory.

In SaxonJ, the functions bin:encode-string() and bin:decode-string() now accept any encoding supported by the Java VM.

In SaxonCS, the functions bin:encode-string() and bin:decode-string() accept any encoding supported by the .NET method Encoding.GetEncoding().

New Extension Functions

Some new extension functions have been added:

Dropped Extension Functions

The saxon:path() function is dropped: use the standard fn:path() function instead.

The undocumented and untested functions saxon:pause-tracing() and saxon:resume-tracing() have been dropped. (The underlying methods in the Controller class remain available if required).

A number of extension functions in the Saxon namespace have not been carried forward to the SaxonCS product, either because they are obsolete, or because implementation is non-trivial. These include saxon:compile-query, saxon:is-defaulted, saxon:key-map, saxon:last-modified, saxon:parse-dateTime, saxon:send-mail, saxon:query, saxon:unparsed-entities.

Some EXSLT and EXPath function libraries are not implemented in SaxonCS, including the EXSLT date/time library and the EXPath archive library.

Extension Instructions

The saxon:array instruction has changed to work the same way as the proposed XSLT 4.0 xsl:array instruction: it has an attribute composite="yes|no". With composite="yes", the members of the new array may be arbitrary sequences, and should be constructed using saxon:array-member (or fn:parcel()). With composite="no", the members of the array must be singletons, and are returned by the sequence constructor as a normal sequence of items.

The saxon:for-each-member instruction, introduced in Saxon 10, has been dropped. For new alternative methods to interate over the members of an array, see Iterating over maps and arrays.

XPath Syntax Extensions

The range expression A to B has been extended to allow A by S to B, for example 1 by 3 to 10 returns (1, 4, 7, 10). The step may be negative: 10 by -1 to 6 returns (10, 9, 8, 7, 6).

The ternary conditional syntax A ?? B !! C is implemented (it is semantically equivalent to if (A) then B else C). The syntax is borrowed from Perl6.

The Tuple type construct tuple(x,y,x) is now renamed record(x,y,z), though the old keyword is retained for compatibility. The flag "?" after a field name, indicating that the field is optional, is now implemented; permitting an empty sequence is no longer enough to make the field optional.

The function conversion rules (which determine how the supplied value for a function argument or XSLT variable can differ from the declared type) now allow downcasting. For example, if the required type is declared as xs:positiveInteger then the supplied value can be 42: there is no longer any need for the caller to cast it as xs:positiveInteger(42). Of course, an error occurs if the cast fails. The effect of this is to make derived types such as xs:positiveInteger much more usable. Note that this rule doesn't allow any casting operation, only a strict relabelling of the supplied value. For example, if the required type is xs:integer then you can supply the decimal value 3.0, but you can't supply 3.1, even though casting 3.1 to xs:integer is allowed.

XSLT extensions

An extension instruction can be used to invoke a named template. For example, a template with name x:error with declared parameters message and code might be called using the instruction <x:error message="Intoxication detected" code="ABXZ9275"/>, in place of an xsl:call-template instruction with multiple xsl:with-param children. For details, see Extension instructions calling templates.

The syntax of match patterns is extended to make it easier to match maps and arrays, see Match patterns.

A number of proposed new instructions are available:

Some new attributes are available on existing XSLT 3.0 instructions:

In general, streamability of new constructs introduced beyond XSLT 3.0 has not been addressed in the specification or in testing. Constructs that are handled purely at compile time (such as the ternary operator A ?? B !! C) should work without problems, but constructs requiring run-time support will generally not be streamable.