Schema-aware queries and transformations

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

• Schema information is available to the XSLT or XQuery processor at compile time, which enables type information to be used both for diagnostics and for optimization.

• Input documents can be validated against the schema; the resulting type annotations on the nodes in the document can inform how the document is processed. For example, comparing two attributes @price and @discount that have been identified (by schema validation) as numeric can compare them as numbers rather than as strings.

• Constructed output can be validated, thus enabling bugs in the query or stylesheet that cause invalid output to be produced to be debugged more easily.

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

• Using the xsl:import-schema declaration in an XSLT stylesheet.

• Using the import schema declaration in an XQuery prolog.

• Using xsi:schemaLocation (or xsi:noNamespaceSchemaLocation) attributes within the source documents.

• Using the -xsd option on the command line.

• Loading a schema into the configuration using the Java API (see Validation from Java) or the C# API (see Validation from C#).

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 query or stylesheet attempts to produce invalid output, you will usually get an error message that identifies the offending instruction in the query or stylesheet.