Schema-Aware Queries and Transformations

Schema-awareness, in both XSLT and XQuery, has three effects:

The schema to be used can be specified in a number of ways:

Although you can load multiple schema documents into a single Configuration, they are assembled into a single schema (that is, a collection of schema definitions) which must be internally consistent. For example, you cannot have two different definitions of the same type. This creates limitations: if you want to write a transformation that converts documents from version 1 of a schema to version 2 of the same schema, you will typically be able to validate either the input or the output, but not both.

Validating the source document has several effects. Most obviously, it will cause the transformation to fail if the document is invalid. It will also cause default values for attributes and elements to be expanded, so they will appear to the query or stylesheet as if they were present on the source document. In addition, element and attribute nodes that have been validated will be annotated with a type. This enables operations to be performed in a type-safe way. This may cause error messages, for example if you try to use an xs:decimal value as an argument to a function that expects a string. It may also cause some operations to produce different results: for example when using elements or attributes that have been given a list type in the schema, the typed value of the node will appear in the stylesheet as a sequence rather than as a single string value.

XSLT also allows you to validate constructed elements and result documents (both final result documents and temporary trees), using the validation and type attributes. Similarly, XQuery allows you to validate constructed elements using the validate{} instruction. Validation of constructed nodes is done on-the-fly as they are created, so if the stylesheet attempts to produce invalid output, you will usually get an error message that identifies the offending instruction in the query or stylesheet.