Schema-aware XSLT and XQuery from Java and C#

If a query or stylesheet is schema-aware, it will typically expect the principal input document to be schema-validated. There are a number of ways this can be achieved:

• The equivalent of the -val command-line option is to set the configuration property SCHEMA_VALIDATION.

  This option switches validation on for all source documents used by any transformation within this Configuration. Setting the value to lax, which performs validation only if a schema is available, is sometimes appropriate, but for most applications of any complexity the value strict tends to result in spurious failures, resulting from attempts to validate documents for which no schema exists.

• The source document can be parsed and built into a tree before the query or transformation starts, typically by using a DocumentBuilder set to perform schema validation, or by using a SchemaValidator with its destination set to an XdmDestination.

  Note: building the document this way means that whitespace stripping will not be under the control of xsl:strip-space and xsl:preserve-space declarations in the stylesheet.

• For any method that expects a Source as input (for example, the transform() method in an XSLT transformer), it is possible to supply an instance of the class 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.

Within an application, a schema should only be compiled once into an XdmSchema object. Compiling it once to validate a source document, and again to satisfy a schema import in XSLT or XQuery, is likely to lead to errors (quite apart from being inefficient).

The configuration property VALIDATION_WARNINGS 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.

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 supply an XdmDestination as the destination for the query or transformation results. From this you can extract the XdmNode representing the root of the tree, and thence navigate to other nodes in the tree. To get the actual type annotation you need to drop into lower-level Saxon interfaces, by obtaining the underlying NodeInfo object and calling its getSchemaType() method.