<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="schema-processing" page="satransformcmd" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Schema-Aware XSLT from the Command Line</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Schema-Aware XSLT from the Command Line"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Schema-Aware XSLT from the Command Line</h1>
<p>To run a schema-aware transformation from the command line, use the <a class="bodylink" href="../javadoc/com/saxonica/Transform.html"><code>com.saxonica.Transform</code></a> command
instead of the usual <code>net.sf.saxon.Transform</code>. This has an additional option <code>-val:strict</code> to
request strict validation of the source document, or <code>-val:lax</code> for lax validation. This applies not
only to the principal source document loaded from the
command line, but to all documents loaded via the <code>doc()</code> and <code>document()</code> functions.</p>
<p>The schemas to be used to validate these source documents can be specified either by using the
<code>xsl:import-schema</code> declaration in the stylesheet, or using <code>xsi:schemaLocation</code>
(or <code>xsi:noNamespaceSchemaLocation</code>) attributes within the source documents themselves,
or by using the <code>-xsd</code> option on the command line.</p>
<p>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 <code>xs:decimal</code> 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.</p>
<p>Saxon-EE also allows you to validate result documents (both final result documents
and temporary trees), using the <code>validation</code> and <code>type</code> 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
<code>Result</code> object (whether it's a <code>StreamResult</code>, <code>SAXResult</code>, or <code>DOMResult</code>,
but they remain available if you capture the output in a Saxon <code>Receiver</code> or in a <code>DOMResult</code>
that encapsulates a Saxon <a class="bodylink" href="../javadoc/net/sf/saxon/om/NodeInfo.html"><code>NodeInfo</code></a>. For details of the way in which type annotations are represented
in the Saxon implementation of the data model, see the JavaDoc documentation. The <code>getTypeAnnotation()</code>
method on a <code>NodeInfo</code> object returns an integer fingerprint, which can be used to locate the name of the
relevant type in the <a class="bodylink" href="../javadoc/net/sf/saxon/om/NamePool.html"><code>NamePool</code></a>. The <code>NamePool</code> also provides the ability to locate the actual
type definitions in the schema model, starting from these integer fingerprints.</p>
<p>The <code>-vw</code> 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 <code>validation</code> attribute of <code>xsl:result-document</code>.</p>
<p>With the schema-aware version of Saxon, type declarations (the <code>as</code> attribute on elements such as
<code>xsl:function</code>, <code>xsl:variable</code>, and <code>xsl:param</code>) can refer to schema-defined types,
for example you can write <code><xsl:variable name="a" as="schema-element(ipo:invoice)"/></code>. You can also use
the <code>element()</code> and <code>attribute()</code> tests to select nodes by their schema type in path expressions
and match patterns.</p>
<p>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 <code>match="schema-element(invoice)"</code>,
then it will check any path expressions used in the template rule to ensure that they are valid against the schema
when starting from <code>invoice</code> as the context node. Similarly, if the result type of a template rule
or function is declared using an <code>as</code> 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.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="satransformapi.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
