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 believe the statement is true, and I don't understand your reasoning for
saying it isn't. I don't understand the terms "evaluated against" and "blind
looping". 

$a establishes the focus for evaluating the expression on the rhs of "/",
but a variable reference has no dependency on the focus. It depends only on
the set of variable bindings in its static context, and the static context
for $b is not affected by $a.

I can't see what's special if $b contains a sequence of xs:QName values. The
interpretation of an xs:QName value doesn't depend either on the static or
the dynamic context.


> > > 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'm puzzled by this. Most people seem to suggest that context-dependencies
in the language make it difficult to learn and to teach, but you seem to be
suggesting the opposite. 

The rh operand of "/" is indeed evaluated in a dynamic context that is
influenced by the lh operand. Specifically, the lh operand determines the
part of the dynamic context called the "focus", consisting of the context
item, position, and size. But the value of an integer does not depend on the
context item, position, or size, so this has no effect on the outcome.  
> 
> 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 

I don't understand this notion of converting things into QNames. 

In a conventional path expression such as a/following-sibling::*, how would
I convert following-sibling::* into a QName?

Michael Kay
http://www.saxonica.com/

Received on Thursday, 28 April 2005 07:22:00 UTC