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:strict
to request strict validation of the source document, or
-val:lax
for lax validation. 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, or by using the -xsd
option on the command line.
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
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.
Saxon-EE 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 getSchemaType()
method on a NodeInfo object returns a SchemaType object representing the type.
The -outval:recover
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.
Saxon does a certain amount of static analysis of the XSLT and XPath code based on schema
information. For example, if a template rule is defined with a match pattern such as
match="schema-element(invoice)"
, then it will check any path expressions
used in the template rule to ensure that they are valid against the schema when starting
from invoice
as the context node. Similarly, if the result type of a template
rule or function is declared using an as
attribute, then Saxon will check any
literal result elements in the body of the template or function to ensure that they are
consistent with this declared type. This analysis can reveal many simple user errors at
compile time that would otherwise result in run-time errors or simply in incorrect output.
But this is only possible if the source code explicitly declares the types of parameters,
template and function results, and match patterns.