Re: Variable references in path expressions

> > >
> > No, I did not mean
> >
> > return $a/eval($b)
> >
> > 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)

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

Anyway, if we are able to do things like de-duplicate, document ordering,
homogeneous sequence or not kind of check, although all on the
resulting sequence, I don't see why a conversion can't be done
on the rhs sequence. The XQuery processor know explicitly that
its dealing with a variable reference and a variable
reference is always bound to a sequence.

The current behaviour is due to how the semantics has been
designed. I still can't see that it is an effect of the grammar.
Anyway, thanks for all replies, especially those from Michael Kay
it does help to sharpen my thinking on the issues involved.

I do not wish to raise it as an issue unless there are more who
feel the same as I did. WG has too much on its plate
already. Let's hope that XQuery can be shipped soon.

I can live with the flaw and it can be corrected easily in 2.0
if there is wide spread feedback on the bug.

regards,
Kuan Hui

Received on Friday, 29 April 2005 17:49:48 UTC