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 such as 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 Configuration.