Packaging, installation, and licensing changes
A new configuration property DEFAULT_REGEX_ENGINE is supported.
The value indicates which regular expression engine will be used for evaluating regular expressions in XPath functions
matches(), XSLT instructions such as
<xsl:analyze-string>, and in XSD pattern
facets. The possible values are "S" (the default) indicating the Saxon regular expression engine (derived from Apache Jakarta), "J"
for the Java JDK regex engine, and "N" for the Microsoft .NET regex engine (available on the .NET platform only). When
the options "J" or "N" are used, regular expressions must follow the syntax and semantics of the chosen engine, rather than the
W3C XPath and XSD rules.
The particular trigger for adding this option was a user's need to do validation using schemas written for the Microsoft XSD processor, which uses Microsoft's regex dialect in its pattern facet rather than the W3C regex dialect. There is no guarantee that this makes Saxon's XSD processor bug-compatible with Microsoft's processor in every respect, but it brings it closer.
New configuration options have been added allowing the
UnparsedTextURIResolver (used for dereferencing
URIs passed to
unparsed-text() and related functions) to be set at Configuration level, including
via the Configuration file.
There is a new configuration property MAX_COMPILED_CLASSES to put a cap on the
number of classes compiled when bytecode generation is
enabled. This is to prevent the situation where the cost of generating such classes, and the memory they occupy,
starts to exceed any benefit. The default value is 10,000 (ten thousand). If the limit is exceeded, Saxon falls back
to using interpreted mode for any remaining functions or templates that have not yet been compiled. The limit applies
to the entire VM, not just to one