Re: Comments on XPointer 1.0 CR

   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