XSLT 3.0 implementation
Saxon 9.8 allowed
xsl:merge-source/@for-each-stream as a synonym for
xsl:merge-source/@for-each-source, to ease transition from the XSLT 3.0 Candidate Recommendation.
This synonym has now been dropped.
xsl:try/@rollback-output="no" is now implemented. When evaluated in push
mode, the output of the
xsl:try is written to the result tree destination, and the
xsl:catch takes effect only if no output has been written at the time the dynamic
The XSLT 3.0 specification states:
In previous versions of this specification it was stated that when the raw result of the initial template or function is an empty sequence, a result tree should be produced if and only if the transformation generates no secondary results (that is, if it does not invoke xsl:result-document).... Processor APIs offering backwards compatibility with earlier versions of XSLT must respect this behavior, but there is no requirement for new processor APIs to do so.
Saxon 9.9 changes so that a principal result is always generated, even if it is empty, regardless whether
any secondary results have been produced. This means, for example, that when running a transformation from
the command line with
-o:dummy.xml, where all output from the stylesheet is sent to specific
xsl:result-document, an empty
dummy.xml file will now be written.
The XSLT 3.0 specification permits processors to support XPath 3.1, but also requires them to provide a mode of operation that only supports XPath 3.0. Saxon supports XPath 3.1 by default, but in the interests of conformance, a configuration option XPATH_VERSION_FOR_XSLT has been added; if set to the integer value "30", XPath expressions are restricted to use XPath 3.0 syntax, plus the extensions to XPath 3.0 syntax defined in the XSLT 3.0 recommendation.
In 9.8, it was possible to export a SEF file using Saxon-EE with the options
-target:HE, and provided the stylesheet used no Saxon-PE or Saxon-EE facilities, it could then be
executed on a run-time version of Saxon with no license key - but only by downloading the Saxon-PE software.
(However, see bug 3859.) This has now been rationalized: such a SEF file can now be executed using Saxon-HE alone.
SEF files generated using Saxon 9.8 will in many cases continue to work using Saxon 9.9, but this has not been thoroughly tested, so recompiling is recommended.
The data tables used to decide whether a character is alphanumeric, used primarily to support
have been regenerated from Unicode 10.0.0 (previously Unicode 4.0.0 was used).
In previous releases, Saxon passed all the W3C XSLT 3.0 test cases, but there were a few discrepancies on error tests where the wrong error code was generated. In 9.9, for the first time, the generated error codes in all cases match the test expectations.