This class holds details of user-selected configuration options for a set of transformations and/or queries. When running XSLT, the preferred way of setting configuration options is via the JAXP TransformerFactory interface, but the Configuration object provides a finer level of control. As yet there is no standard API for XQuery, so the only way of setting Configuration information is to use the methods on this class directly.
As well as holding configuration settings, this class acts as a factory for classes providing service in particular areas: error handling, URI resolution, and the like. Some of these services are chosen on the basis of the current platform (Java or .NET), some vary depending whether the environment is schema-aware or not.
The Configuration provides access to a {@link NamePool} which is used to manageall the names used in stylesheets, queries, schemas, and source and documents: the NamePool allocates integer codes to these names allowing efficient storage and comparison. Normally there will be a one-to-one relationship between a NamePool and a Configuration. It is possible, however, for several Configuration objects to share the same NamePool. Until Saxon 8.9, by default all Configuration objects shared a single NamePool unless configured otherwise; this changed in 8.9 so that the default is to allocate a new NamePool for each Configuration.
The Configuration establishes the scope within which node identity is managed. Every document belongs to a Configuration, and every node has a distinct identity within that Configuration. In consequence, it is not possible for any query or transformation to manipulate multiple documents unless they all belong to the same Configuration.
Saxon-SA has a subclass of the Configuration class which provides the additional services needed for schema-aware processing. The {@link com.saxonica.validate.SchemaAwareConfiguration}also holds a cache of loaded schema components used for compiling schema-aware transformations and queries, and for validating instance documents.
Since Saxon 8.4, the JavaDoc documentation for Saxon attempts to identify interfaces that are considered stable, and will only be changed in a backwards-incompatible way if there is an overriding reason to do so. These interfaces and methods are labelled with the JavaDoc "since" tag. The value 8.n indicates a method in this category that was introduced in Saxon version 8.n: or in the case of 8.4, that was present in Saxon 8.4 and possibly in earlier releases. (In some cases, these methods have been unchanged for a long time.) Methods without a "since" tag, although public, are provided for internal use or for use by advanced users, and are subject to change from one release to the next. The presence of a "since" tag on a class or interface indicates that there are one or more methods in the class that are considered stable; it does not mean that all methods are stable.
@since 8.4