# Schema-Aware XSLT from the Command Line

To run a schema-aware transformation from the command line, use the `com.saxonica.Transform` command instead of the usual `net.sf.saxon.Transform`. This has an additional option `-val` to request validation of the source document. This applies not only to the principal source document loaded from the command line, but to all documents loaded via the `doc()` and `document()` functions.

The schemas to be used to validate these source documents can be specified either by using the `xsl:import-schema` declaration in the stylesheet, or using `xsi:schemaLocation` (or `xsi:noNamespaceSchemaLocation`) attributes within the source documents themselves.

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 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 attribute 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.

Saxon-SA also allows you to validate result documents (both final result documents and temporary trees), using the `validation` and `type` attributes. For details of these, refer to the XSLT 2.0 specification. Validation of result documents is done on-the-fly, so if the stylesheet attempts to produce invalid output, you will usually get an error message that identifies the offending instruction in the stylesheet. Type annotations on final result documents are lost if you send the output to a standard JAXP `Result` object (whether it's a `StreamResult`, `SAXResult`, or `DOMResult`, but they remain available if you capture the output in a Saxon `Receiver` or in a `DOMResult` that encapsulates a Saxon `NodeInfo`. For details of the way in which type annotations are represented in the Saxon implementation of the data model, see the JavaDoc documentation. The `getTypeAnnotation()` method on a `NodeInfo` object returns an integer fingerprint, which can be used to locate the name of the relevant type in the `NamePool`. The `NamePool` also provides the ability to locate the actual type definitions in the schema model, starting from these integer fingerprints.

The `type` attribute is not currently supported on instructions that create document nodes, as distinct from element or attribute nodes.

The `-vw` option on the command line causes validation errors encountered in processing a final result tree to be treated as warnings, allowing processing to continue. This allows more than one error to be reported in a single run. The result document is serialized as if validation were successful, but with XML comments inserted to show where the validation errors were found. This option does not necessarily recover from all validation errors, for example at present it does not recover from errors in uniqueness or referential constraints. It applies only to result trees validated using the `validation` attribute of `xsl:result-document`.

With the schema-aware version of Saxon, type declarations (the `as` attribute on elements such as `xsl:function`, `xsl:variable`, and `xsl:param`) can refer to schema-defined types, for example you can write `<xsl:variable name="a" as="schema-element(ipo:invoice)"/>`. You can also use the `element()` and `attribute()` tests to select nodes by their schema type in path expressions and match patterns. See conformance.html to check which parts of the syntax have been implemented.

The W3C Working Groups have agreed changes to this part of the XPath syntax since the last published working draft in November 2003, and Saxon implements these changes. The constructs allowed are:

- `element()`, which matches any element

- `element(N)`, which matches any element named N

- `element(N, T)`, which matches any element whose name is N and whose type annotation is T or a subtype of T. T must be a global type declaration (simple or complex) in an imported schema.

- `schema-element(N)`, which matches any element whose name is N or a member of the substitution group headed by element N, and whose type is the same as (or a subtype of) the declared type of N. Here N must be the name of a global element declaration in an imported schema.

Similar constructs are defined for attributes.

Saxon does not at present do any static analysis of the XSLT or XPath code based on schema information, other than checking that all schema types that are referred to have actually been defined in an imported schema.

Expand | Next