Re: Variable references in path expressions

>
> Consider the path expression $a/$b.
 >
 > If $a is a singleton, then the expression is equivalent to $b.
>
This is not true because it is dependent on the items contained
in $b which is subjected to path interpretation. Say, if $b contained
a list of QName items, then it has to be evaluated against $a
and not some blind looping.

I totally disagree with the above generalization which is
dangerously misleading.

> >
> > However, if $a is not a singleton, then a query such as
> >
> >     let
> >       $a := (<a1/>, <a2/>, <a3/>),
> >       $b := (1, 2, 3)
> >     return
> >       $a/$b
> >
> > will return
> >
> >     (1, 2, 3, 1, 2, 3, 1, 2, 3)

This side-effect is really disturbing; a path operator is now
treated blindly as an iterator in the presence of a sequence
in the follow-on expression without regard for the context
in which it is evaluated. This can be confusing to preach
and can potentially make XQuery painful to debug.

I suggest that the atomic values returning from the last
step must be a result of evaluating against the preceding
step. Wherein the above example, there should be an
attempt to convert each item into a QName to evaluate
against the previous resulting sequence; failing which
we should throw an error instead. This will keep the
semantics of the path expression intact. In your
example, the numerics 1,2,3 cannot be converted to
QNames and therefore should throw an error.

I can appreciate your example if it is,

   $a/fxn123()

> >
> >     let
> >       $a := (<a1/>, <a2/>, <a3/>),
> >       $b := (<b1/>, <b2/>, <b3/>)
> >     return
> >       $a/$b
> >
> > return
> >
> >     (<b1/>, <b2/>, <b3/>, <b1/>, <b2/>, <b3/>, <b1/>, <b2/>, <b3/>)
> >
> > because the expression bound to $b constructs unique elements
> > each time it is evaluated?
>
> Yes.
>
> > Or should (<b1/>, <b2/>, <b3/>) be returned?

I appreciate the subtlety of the significance of node identity
being highlighted. However, to preserve the semantics of
path expressions, can I also suggest that there is an attempt
to convert every item in $b into QNames for evaluation.
We can throw an error or warn if the conversion fails
or quietly convert the item into () for evaluation but
not making the path operator "/" into a blind iterator.

If an iteration construct is required, please advocate
alternative syntax so as to keep the xpath semantics
consistent.

Received on Thursday, 28 April 2005 01:22:42 UTC