xsl-list
[Top] [All Lists]

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

2008-03-21 12:11:24

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/


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>