Re: Variable references in path expressions

TAN Kuan Hui wrote:
> 
> > > Again, it is the way "/" interpretes its rhs operand and not the
> > > presence of a sequence being re-interpreted as a set of
> > > parsing tokens.
> > >
> > > I see "/" as a operator in this same context. No ?
> > > Unreasonable expectation or intuition ?
> >
> > If slash were an operator, then one would evaluate a 'slash expression'
> > (i.e., an expression in which slash was the (top) operator) by
> > evaluating its left and right operands (in an implementation-dependent
> > order), and then applying the semantics of the slash operator to the
> > values of those operands. I think what you're saying might make sense
> > in such a world.
> >
> > However, slash is not an operator, it does not have operands, and
> > one does not evaluate expressions-involving-slash (i.e., PathExprs)
> > in that way.
>
> Thanks Michael for highlighting this. I did verify the definition back
> to XPath 1.0. The semantics did clearly mention "/" and "//"
> as an operator. (see 3.3 Node-sets of XPath 1.0)

True, the XPath 1.0 spec does say this. However, you may have noticed
that the XPath 2.0 does not. My guess is that the authors realized it was
an inappropriate use of the word.

Anyway, my point does not hinge on whether '/' is *called* an operator,
but rather whether it *is* an operator -- that is, whether it has the
general evaluation semantics I gave before (evaluate the lhs and rhs
independently, then combine the resulting values in a slash-specific
way). You appear to think that it has, or could easily be given, such
semantics. I'm hoping you'll realize that it does not, and could not.

> I am concern about evaluating only the rhs. The following
> production shows that we can do something to the rhs of "/"
> prior to evaluating the expression.
> 
> [67]    PathExpr    ::=    ("/" RelativePathExpr?)
>                                     | ("//" RelativePathExpr)
>                                     | RelativePathExpr /* gn: leading-lone-slash */
> [68]    RelativePathExpr    ::=    StepExpr (("/" | "//") StepExpr)*

Why do you think these productions show that? It's the normalization
and evaluation rules, not the grammar productions, that dictate
whether we can "do something" to a StepExpr prior to evaluating the
expression.

-Michael Dyck

Received on Friday, 29 April 2005 21:54:42 UTC