- From: Daniel Veillard <Daniel.Veillard@w3.org>
- Date: Tue, 3 Oct 2000 15:40:38 +0200
- To: Michael Dyck <MichaelDyck@home.com>
- Cc: www-xml-linking-comments@w3.org
Hi Michael, Sorry it took so long to get back, but I didn't want to come back with an answer without having tried it with running code that time. And of course it took longer than expected to get back to my XPath code and check what was really needed. On Sun, Sep 17, 2000 at 05:20:06PM -0700, Michael Dyck wrote: > Daniel Veillard <Daniel.Veillard@w3.org> > > > > the change is a single addition to the production [3] of the XPath > > specification: > > > > [3] RelativeLocationPath ::= Step | > > RelativeLocationPath '/' Step | > > AbbreviatedRelativeLocationPath > > > > Basically this is a single exception for the range-to() function. > > It is not a generic change and not extendable to other functions. > > This is used to express that a range computation must be made for > > each of the nodes in the current nodelist. The Modified XPath > > production becomes: > > > > [3xptr] RelativeLocationPath ::= Step | > > RelativeLocationPath '/' Step | > > AbbreviatedRelativeLocationPath | > > 'range-to(' RelativeLocationPath ')' > > This BNF does not achieve what you want. Specifically, it does not allow > you to parse the "range-to" examples in section 5.4.1. (Try it!) Agreed, and I did want to try it ! Hence the delay > Moreover, though not needed to parse the examples: > > (3) Instead of > 'range-to(' > I think you should say > 'range-to' '(' > (to get the tokenization right). Very good point, there is possibly spaces interleaved which the XPath productions don't show but should be accepted anyway. 'id("chapter1")/range-to(id("chapter2"))' and 'id("chapter1")/range-to ( id("chapter2") )' are both okay. > (4) Might one want to apply predicates to the result of a 'range-to'? Why not, yes I don't see why they should not be allowed. > Thus, I suggest: > [4xptr] Step ::= AxisSpecifier NodeTest Predicate* > | AbbreviatedStep > | 'range-to' '(' Argument ')' Predicate* > > However, there's one niggling technicality. Presumably you want such a use > of "range-to" to have the semantics of an XPath FunctionCall (see XPath > section 3.2), but although it looks like a FunctionCall, it isn't > (according to this BNF). Now you could fudge it and say that "in a Step of > the third form, the 'range-to' '(' Argument ')' portion should be > evaluated as if it were a FunctionCall", but that's kludgey. Instead, you > could say > > [4xptr] Step ::= ... > | ... > | FunctionCall Predicate* > > and then add a VC saying that the only FunctionName currently allowed in > such a context is 'range-to'. Still a little kludgey, but in my opinion > it's the minimal-kludge solution. A couple of things: 1/ I don't like not having any indication to the programmer about how he's supposed to parse the "Argument" that woudl be worse than the current situation 2/ I think this "Argument" is actually a LocationPath this allows to parse both examples from the spec and more complex ones like id("chapter1")/range-to(/p/id("chapter2")) for example 3/ I would rather not associate this range-to construct with a conction call. This is a completely different beast at the semantic level (and the very serious problem you pointed out when starting this thread, I personally consider it more close to a Predicate evaluation than a function call actually). After some testing my recommendation is now the following: ----------------------------------- The change made to [XPath] syntax to support the range-to construct is a single addition to the production [4] of the XPath specification: [4] Step ::= AxisSpecifier NodeTest Predicate* | AbbreviatedStep Basically this is a single exception for the range-to() function. It is not a generic change and not extendable to other functions. This is used to express that a range computation must be made for each of the nodes in the current nodelist. The Modified XPath production becomes: [4xptr] Step ::= AxisSpecifier NodeTest Predicate* | AbbreviatedStep | 'range-to' '(' LocationPath ')' Predicate* The range-to derivation of the [4xptr] prodution is not allowed from a LocationPath itself the result of a range-to derivation of [4xptr]. ----------------------------------- I hope this this good enough to close the issue, Daniel P.S: I will commit the associated code to the xpath.c module of libxml later today, it probably won't be functionnally okay, but the parsing code should be okay. It affects a single function xmlXPathEvalStep(). -- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe
Received on Tuesday, 3 October 2000 09:40:51 UTC