[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath 2.0 Best Practice: wrap the first node of ev

Subject: Re: 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
Re:  XPath 2.0 Best Practice: wrap the first node of ev
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.