SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Notices
Using XSLT 2.0
Using XQuery
Handling Source Documents
| Handling Source Documents
| Source Documents on the Command Line
| Collections
| Building a Source Document from an application
| Preloading shared reference documents
| Writing input filters
| XInclude processing
| Saxon and XML 1.1
| JAXP Source Types
| Third-party Object Models: DOM, JDOM, XOM, and DOM4J
| Choosing a Tree Model
| The PTree File Format
» | Validation of Source Documents
| Whitespace Stripping in Source Documents
| Streaming of Large Documents
| Document Projection
XML Schema Processing
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

# Validation of Source Documents

With Saxon-SA, source documents may be validated against a schema. Not only does this perform a check that the document is valid, it also adds type information to each element and attribute node in the document to identify the schema type against which it was validated. It may also expand the source document by adding default values of elements and attributes.

If the option `-val:strict` is specified on the command line for `com.saxonica.Query` or `com.saxonica.Transform`, then the principal source document to the query or transformation is schema-validated, as is every document loaded using the `doc()` or `document()` function. Saxon will look among all the loaded schemas for an element declaration that matches the outermost element of the document, and will then check that the document is valid against that element declaration, reporting a fatal error if it is not. The loaded schemas include schemas imported statically into the query or stylesheet using `import schema` or `xsl:import-schema`, schemas referenced in the `xsi:schemaLocation` or `xsi:noNamespaceSchemaLocation` attributes of the source document itself, and schemas loaded by the application using the `addSchema` method of the `Configuration` object.

As an alternative to `-val:strict`, the option `-val:lax` may be specified. This validates the document if and only if an element declaration can be found. If there is no declaration of the outermost element in any loaded schema, then it is left as an untyped document.

When invoking transformations or queries from the Java API, the equivalent of the `-val:strict` option is to call the method `setSchemaValidation(Validation.STRICT)` on the `Configuration` object. The equivalent of `-val:lax` is `setSchemaValidation(Validation.LAX)`.

When documents are built using the `DocumentBuilder` in the s9api interface, or in the Saxon.Api interface on .NET, validation may be controlled by setting the appropriate options on the `DocumentBuilder`.

On Java interfaces that expect a JAXP `Source` object it is possible to request validation by supplying an `AugmentedSource`. This consists of a `Source` and a set of options, including validation options; since `AugmentedSource` implements the JAXP `Source` interface it is possible to use it anywhere that a `Source` is expected, including as the object returned by a user-written `URIResolver`.

Saxon's standard `URIResolver` uses this technique if it has been enabled (for example by using `-p` on the command line). With this option, any URI containing the query parameter `?val=strict` (for example, `doc('source.xml?val=strict')`) causes strict validation to be requested for that document, while `?val=lax` requests lax validation, and `?val=strip` requests no validation.

Next