XSLT 3.0 implementation

Higher order functions and the xsl:evaluate instruction are now available in Saxon-HE.

Error XTDE1160 (which occurs when an invalid fragment appears in the URI passed to the document() function) is now reported unconditionally; it is no longer a recoverable error. This change is in line with the XSLT 3.0 specification. This was the last remaining "recoverable error", and in consequence, the configuration options controlling how recoverable errors were handled have now been dropped.

Deterministic functions (specifically, the option <xsl:function new-each-time="no">) are now available in Saxon-HE as well as Saxon-PE and Saxon-EE. This change is made because it is Saxonica policy that all mandatory features of the XSLT 3.0 specification should be available in Saxon-HE. Note: these functions are implemented as memo functions: the results of previous calls are remembered, and if a new call is made with the same arguments, the remembered result is returned. The main use case is in fact for the performance effect (using more memory to achieve higher speed) rather than for the rather technical effect of returning repeatable results. Setting the option cache="yes" achieves the same effect.

Some extensions to XSLT 3.0 streaming capability have been implemented:

• The existing higher order function fn:filter, and the new extension functions saxon:items-after, saxon:items-before, saxon:items-from, and saxon:items-until are now streamable, under the right conditions. Provided that the second argument is either:

  1. A function reference to a user-defined stylesheet function declared with streamability=inspection, or
  2. An inline function whose body is grounded and motionless

  then the posture and sweep of the function call are the same as the posture and sweep of the first argument.

  For example, the call saxon:ends-where(/article/*, function($e){$e[@title="Introduction"]}) processes all sections of an article up to and including the one with title "Introduction". This call is striding and consuming (which means that when used in an appropriate context it is streamable).

In interfaces that require Saxon to parse the <?xml-stylesheet?> processing instruction to locate a stylesheet, the parsing of the instruction now follows the W3C specification much more rigorously, meaning that errors may now be detected that previously passed unnoticed.

Saxon 10 is capable of generating SEF files suitable for Saxon 10 or Saxon-JS 2.0. The formats are different (the most obvious difference is that SEF files for Saxon 10 are in XML format, while those for Saxon-JS 2.0 are in JSON), so the right target must be selected when exporting. SEF files generated using Saxon 10 cannot be loaded by Saxon 9.9 or by Saxon-JS 1.x. SEF files generated using Saxon 9.9 or earlier releases cannot be loaded by Saxon 10.