Subject: Re: [xsl] XPath 2.0 Best Practice: wrap the first node of every path expression within schema-element? From: David Carlisle <davidc@xxxxxxxxx> Date: Thu, 27 Mar 2008 12:30:59 GMT |
> 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. ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XPath 2.0 Best Practice: , Mukul Gandhi | Thread | Re: [xsl] XPath 2.0 Best Practice: , Mukul Gandhi |
Re: [xsl] Managing XSLTS for XSLFO , Kamal | Date | Re: [xsl] XPath 2.0 Best Practice: , Florent Georges |
Month |