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: "Mukul Gandhi" <gandhi.mukul@xxxxxxxxx>
Date: Thu, 27 Mar 2008 18:28:02 +0530
Thanks David for helpful thoughts ...

On 3/27/08, David Carlisle <davidc@xxxxxxxxx> wrote:
>
>
> >    For this case, some form of static error reporting is already
> > defined in the XPath 2.0 spec. Please see:
>
>
> But XSLT (even when schema aware) distances itself from the statuc
> typing rules as defined in xquery/xpath (for the good reason that they
> are a usability nightmare, as was found in the Xquery test suite (and
> the examples in the XQuery spec) It's just ridiculously difficult to
> write an expression that passes the static typing without putting
> explict casts and calls to exactly-one() everywhere,
>
> To see the slippery slope that you may not want to be on, if the schema
> defines Book to take exactly one Author child (and no Foo children) then
> it seems easy to argue that
>
> schema-element(Book)/Foo  should be an error but what about
> schema-element(Book)/Author
> static typing would force you to write
> schema-element(Book)/Author[1]
> and if you had
> schema-element(Book)/Author[$x]
> you may find yourself having to statically assert that $x is 1.
>
>
> (lmost all the usability problems with the static typing feature in
> xpath relate to cardinality checks as the type system
> distinguishessingletons from lists (corresponding to the occurrence
> indicators ? and *) but in almost all cases the automatic type inference
> can not infer cardinality, so the user has to add extra assertions.
>
>
> that's not to say some extra compile time  warnings and/or errors could
> not usefully be specified for XSLT, but I don't think they should be by
> reference to the currently specified static typing feature of XPath2.
> In particular I think that all types that differ only by occurrence
> indicator should be unified, so if a schema says that an element may
> have 2 author children, statically accept any expression selecting
> author children don't try to be smart about exactly how many.
> But if it says there are no Foo children, generating an error on
> schema-element(Book)/Foo  would probably be a win 9especially if your
> typing is as accurate as mine:-)
>
> David
>
>
> http://www.w3.org/TR/xslt20/#conformance
>
>    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.



-- 
Regards,
Mukul Gandhi

Current Thread