SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
| Introduction
| Running Validation from the Command Line
| Controlling Validation from Java
| Schema-Aware XSLT from the Command Line
» | Schema-Aware XSLT from Java
| Schema-Aware XQuery from the Command Line
| Schema-Aware XQuery from Java
The XPath API
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# 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.om.Validation.STRICT`. Alternatively, you can set the value to `Validation.LAX`. This attribute name is available as the constant `FeatureKeys.SCHEMA_VALIDATION`.

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 `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, `document('source.xml?val=strict')` requests the loading of the file `source.xml` with strict validation.

The attribute `FeatureKeys.VALIDATION_WARNINGS` 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.

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 `SchemaAwareTransformerFactory` 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 `DocumentInfo` object. Note that type annotations are supported only with the TinyTree implementation.

Next