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

XPath API for Java

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.