[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] XPath 2.0 Best Practice: wrap the first node of every path expression within schema-element?


Subject: RE: [xsl] XPath 2.0 Best Practice: wrap the first node of every path expression within schema-element?
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Fri, 21 Mar 2008 19:10:28 -0000

> > Here I wrap the first node in the path expression within
> > schema-element:
> > 
> >     /schema-element(Book)/Author/LastName

I tend to do it differently; I typically declare a global variable

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

and then write the path expression as $root/Book/Author/LastName

But the effect is the same.

I also tend to use schema-element(x) in match patterns

<xsl:template match="schema-element(LastName)"/>

or if LastName isn't global in the schema, then

<xsl:template match="schema-element(Book)/Author/LastName"/>

which means that the static type of the context item is known within that
template. (Provided it can't also be called by name!)

> > 
> > The benefits of doing this are:
> > 
> > 1. At compile-time the processor will validate the Book 
> input element.

Not quite: rather, it will check that the Book element has been validated.
You control the validation typically by -val:strict on the command line.
> > 
> > 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)
> 
> 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.

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.


Michael Kay
http://www.saxonica.com/


Current Thread
Keywords