Make your own free website on

Schema Aware XSLT examples

1. XPath 2.0 best practice: Use Schema awareness syntax in XPath expressions

Roger L. Costello initiated an interesting discussion on XSL-List about using the Schema awareness features in XPath 2.0 expressions.

Inspired by this discussion, I wrote the following Schema aware XSLT stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl=""

<xsl:output method="xml" indent="yes" />

<xsl:import-schema schema-location="books.xsd" />

<xsl:variable name="root" select="/" as="document-node(schema-element(BOOKLIST))"/>

<xsl:template match="/">
        <xsl:for-each select="$root/BOOKLIST/BOOKS/ITEM">
                <xsl:value-of select="AUTHOR" />


This stylesheet runs on the following input XML:

<BOOKLIST xsi:noNamespaceSchemaLocation="books.xsd" xmlns:xsi="">
          <ITEM ..>


          .. more ITEM elements 


To run this stylesheet successfully, the XSLT processor must be invoked with the validation option (for e.g., as follows with Saxon-SA):

java com.saxonica.Transform -val:strict books.xml books.xsl

Validating the input document prior to the XSLT process ensures that XML nodes get required type annotations attached to them, thereby ensuring Schema awareness benefits on XPath expressions.

Roger suggested following benefits of using the Schema aware approach:

1. At compile-time the processor will check that the XML elements have been validated.

2. At compile-time the processor will detect errors in the path expression:

        2.1 Misspelling errors: these spelling errors are caught:

            /schema-element(Book)/Authr/LastName (Author is misspelled)

            /schema-element(Book)/Author/LastNam (LastName is misspelled)

        2.2 Structural errors: suppose the in-scope schema indicates that the only children of
            Author are FirstName and LastName; this error will be caught:

            /schema-element(Book)/Author/Foo (Foo is not a valid child of Author)

Martin Honnen added:

> Is that something that the XSLT/XPath specification requires that these problems are reported as errors? I don't think
> AltovaXML does report such problems although it is a schema aware XSLT 2.0 processor.

Michael Kay provided following explanation:

No, the specification doesn't require these to be reported as errors. In fact, Saxon reports them as warnings. I think that catching these mistakes is one of the main benefits of schema-awareness, but the amount of checking that is done is processor-dependent.

Path expressions that are provably void become an error in XPath 2.0 only if [pessimistic] static typing is enabled. But this is what the XSLT 2.0 spec says about static typing:

There is no conformance level or feature defined in this specification that requires implementation of the static typing features described in [XPath 2.0]. An XSLT processor may provide a user option to invoke static typing, but to be conformant with this specification it must allow a stylesheet to be processed with static typing disabled. The interaction of XSLT stylesheets with the static typing feature of XPath 2.0 has not been specified, so the results of using static typing, if available, are implementation-defined.

Related links:
1.    (courtesy:    Andrew Welch)


Last Updated: Jan 03, 2009