Resolving URIs
Saxon adopts a uniform approach to resolving and dereferencing these URIs.
The general approach is as follows:
The supplied URI reference is first made absolute by resolving against a suitable base URI.
The resulting absolute URI is dereferenced by a 3-step process:
It is first passed to a local user-supplied
ResourceResolver
, registered at the level of a particular component such as theXsltCompiler
,XsltTransformer
,XQueryCompiler
, orXQueryEvaluator
. If no resolver has been supplied, this stage is skipped.Most of these components provide a method
setResourceResolver()
(in Java) or a settable propertyResourceResolver
(in C#) allowing the resolver to be supplied using a lambda expression. In some cases (for legacy reasons) there are also specialized methods for particular kinds of resources: for examplesetURIResolver()
,setSchemaURIResolver()
,setUnparsedTextResolver()
,setModuleURIResolver()
.If the local resolver fails to resolve the URI, it is passed to a resolver registered centrally with the Saxon Configuration. The default resolver at this level is designed to invoke a third-party library called the catalog resolver, which looks up known URIs in an XML-based catalog. By default there is a single built-in catalog containing local copies of popular W3C-defined resources such as the DTDs for XHTML and SVG. Additional catalog files can be registered using an API (Processor.setCatalogFiles() in Java, Processor.SetCatalogFiles() in C#), or from the command line, or from the Saxon configuration file.
The catalog resolver for SaxonJ and SaxonC also has built-in support for URIs using the
classpath
anddata
schemes.The catalog resolver for SaxonCS also has built-in support for URIs using the
data
scheme.- If the URI has still not been resolved, it is then dereferenced using standard
mechanisms provided by the platform: for example,
http
URIs are dereferenced using the Java or .NETHTTP
library, andfile
URIs using the Java or .NET file I/O libraries.
A user-written
ResourceResolver
for the first two steps is typically written as a function (lambda expression) that takes aResourceRequest
as input, and produces aSource
(Java) orResource
(C#) as output.
URIs used within an XML document to refer to external entities (including the DTD) are a little different since they are generally handled by the XML parser, and not by Saxon itself. Nevertheless, Saxon attempts to offer an integrated approach. For more information on this, see Resolving entities.
URIs for result documents produced using the xsl:result-document
instruction
are handled using a ResultDocumentHandler
registered with the XsltTransformer
or Xslt30Transformer
. For more information on how this works in both the Java s9api API and
the Saxon.Api interface on .NET, see Secondary output.