When queries are controlled using the Java API, the equivalent to the -val
option is to create a EnterpriseConfiguration instead of a Configuration object,
and then to call setSchemaValidationMode(net.sf.saxon.om.Validation.STRICT) on this object.
The value Validation.LAX can also be used.
This option switches validation on for all source documents used by any transformation under the control of this
EnterpriseConfiguration. If you want finer control, so that some documents are validated and others are not, you can
achieve this by using the AugmentedSource object. An AugmentedSource is a wrapper around
a normal JAXP Source object, in which additional properties can be set: for example, a property to
request validation of the document. The AugmentedSource itself implements the JAXP Source
interface, so it can be used anywhere that an ordinary Source object can be used, for example as the
first argument to the buildDocument() method of the QueryProcessor, and as the return value from
a user-written URIResolver.
If the PTreeURIResolver is used, it is also possible to control validation for each source document
by means of query parameters in the document URI. For example, doc('source.xml?val=strict') requests
the loading of the file source.xml with strict validation.
The Configuration method setValidationWarnings()
has the same effect as the -vw
option on the command line: validation errors encountered when processing the final result tree are
reported to the ErrorListener as warnings, not as fatal errors. They are also reported
as XML comments in the result tree.
Schemas can be loaded using either of the techniques used with the command-line interface: that is, by specifying
them in the import schema directive in the query prolog, or by including them in an xsi:schemaLocation
attribute in a source document. In addition, they can be loaded using the addSchemaSource() method on the
EnterpriseConfiguration class.
All schemas that are loaded are cached as part of the EnterpriseConfiguration. This is true whether the
schema is loaded explicitly using the Java API, whether it is loaded as a result of import schema in a query,
or whether it is referenced in an xsi:schemaLocation attribute in a source document. There can only
be one schema document loaded for each namespace: any further attempts to load a schema for a given target namespace
will return the existing loaded schema, rather than loading a new one. Note in particular that this means there
can only be one loaded no-namespace schema document. If you want to force loading of a different schema document
for an existing namespace, the only way to do it is to create a new EnterpriseConfiguration.
