Extensive changes have been made to integrate catalog-based URI resolution using the open-source
XmlResolver developed by Norm Tovey-Walsh.
When resolving URIs referring to XML documents, the preferred approach now is to implement the new class
ResourceResolver. The existing JAXP class
URIResolveris still accepted in public-facing APIs for backwards compatibility, but is no longer used internally. The new
ResourceResolveris provided with more information about the nature of the request, which may be useful for some applications.
Specifically, classes such as
Configurationno longer have
On s9api classes such as
setURIResolver()are retained but deprecated; they map internally to calls on
There is now a consistent strategy for fallback from one resolver to another. If the resolver on a local class such as
XsltCompilerreturns null, then the central
Configurationlevel resolver is called; if this returns null, then a system default resolver is called. The default resolver on local classes returns null. The default resolver at
Configurationlevel invokes the external
XmlResolver(though by default, there is no catalog, so this returns null). The system default resolver uses standard JDK methods for resolving
fileURIs, and also includes code for handling
The configuration property
RECOGNIZE_URI_QUERY_PARAMETERSnow applies to all calls on the doc() and document() functions, even if a user-defined URI resolver is in use.
If the Saxon serialization extension property
next-in-chainis used, the relevant URI is now resolved using the Configuration-level common resource resolver, not the Transformer-level resolver.
In previous releases, well-known W3C resources such as the DTD for XHTML were resolved to local copies held within Saxon. These copies are now held in the
XmlResolver. They will therefore not be used if the Configuration-level
ResourceResolveris replaced with a user-written resolver, unless it delegates to the catalog-based
xsl:source-document instruction now allows the document URI to contain a fragment identifier.