Schema-Aware XSLT from Java
When transformations are controlled using the Java JAXP interfaces, the equivalent to the
-val
option is to set the attribute
"http://saxon.sf.net/feature/schema-validation" on the TransformerFactory
to
the value net.sf.saxon.lib.Validation.STRICT. Alternatively, you can set the value to Validation.LAX. This
attribute name is available as the constant Feature.SCHEMA_VALIDATION.name.
This option switches validation on for all source documents used by any transformation
under the control of this TransformerFactory
. 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, notably as the first argument to the
transform
method of the Transformer
, and as the return value
from a user-written URIResolver
.
If the standard Saxon URIResolver
is used, and recognition of query parameters
is enabled, it is also possible to control validation for each source document by means of
query parameters in the document URI. For example,
document('source.xml?validation=strict')
requests the loading of the file
source.xml
with strict validation.
The attribute Feature.VALIDATION_WARNINGS.name has the same effect as the -outval:recover
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.
Schemas can be loaded using either of the techniques used with the command-line interface:
that is, by specifying them in the xsl:import-schema directive in the stylesheet, or
by including them in an xsi:schemaLocation
attribute in a source document. In
addition, they can be loaded using the addSchema()
method on the EnterpriseTransformerFactory class.
All schemas that are loaded are cached as part of the TransformerFactory
(or
more specifically, as part of the Configuration object owned by the TransformerFactory
). This is true
whether the schema is loaded explicitly using the Java API, whether it is loaded as a
result of xsl:import-schema
, 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 TransformerFactory
.
If you are validating the result tree, and you want your application to have access to the
type annotations in the validated tree, then you should specify as the result of the
transformation either a user-written Receiver
, or a DOMResult
that wraps a Saxon NodeInfo
object. Note that type annotations are supported only with the TinyTree implementation.