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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XPath 2.0 Best Practice: , David Carlisle | Thread | Re: [xsl] XPath 2.0 Best Practice: , Florent Georges |
Re: [xsl] XPath 2.0 Best Practice: , Florent Georges | Date | Re: [xsl] XPath 2.0 Best Practice: , Florent Georges |
Month |