Re: Comments on XPointer 1.0 CR

On Tue, Oct 03, 2000 at 11:02:11PM -0700, Michael Dyck wrote:
> Daniel Veillard wrote:
> > 
> > Michael Dyck wrote:
> > > 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"
> 
> Huh? The same way he parses any other non-terminal. "Argument" is a
> non-terminal in the XPath spec
> (http://www.w3.org/TR/xpath.html#NT-Argument).

  Okay, Argument is just an alias for Expr and I never noticed it since
I didn't implemented a specific function for production [17], sorry.
Expr can still derive a PathExpr and hence a LocationPath so the reason
I suggested it is moot.

> >     2/ I think this "Argument" is actually a LocationPath this allows
> >        to parse both examples from the spec
> 
> I think you'll find that this won't work for the first example in Section
> 5.4.1, because 
>     id("chap2")
> is not a LocationPath; it is (among other things) a FilterExpr. The least
> general non-terminal that handles both examples is PathExpr. I considered
> suggesting PathExpr, but then I thought that Argument made more sense
> (from the analogy to function calls). 

  Okay again, I checked by trying to derivate the production manually.
This mean it's time for some debugging of my code :-(
  Moreover it's clear from section 5.4.1. that it's intended to be an
expression in the sense of the production [14] of XPath ...

> >   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 don't understand why you add this restriction. (I don't think it's
> necessary.)

  Agreed it's not necessary.

-----------------------------------
  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' '(' Expr ')' Predicate*
-----------------------------------

  We could use Argument instead of Expr but in that case the prose in
5.4.1 should be changed from
  "found by evaluating the expression argument"
to
  "found by evaluating the argument" 
and the link would have to be changed
     to http://www.w3.org/TR/xpath.html#NT-Argument

  I will submit this question to the WG,

Daniel

-- 
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 Wednesday, 4 October 2000 05:49:14 UTC