Re: Comments on XPointer 1.0 CR

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).

>     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). 

>     3/ I would rather not associate this range-to construct with a
>        conction call.

Then why does section 5.4.1 introduce it as a function?

>     This is a completely different beast at the semantic level

I disagree. It evaluates its argument in the current context and yields a
result. How is that semantically different from a function?

>   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.)

-Michael Dyck

Received on Wednesday, 4 October 2000 02:07:13 UTC