Re: Variable references in path expressions

TAN Kuan Hui wrote:
> 
> >
> > >
> > > I might be mistaken, but I think he wants to do this:
> > >  > let $a := (<a/>,<b/>,<c/>)
> > >  > let $b := (xs:QName("b"), xs:QName("c"))
> > >  > return $a/$b
> > > .. would lead to $a being filtered by $b's QNames on the
> > > child axis, so
> > > the result would be <b/>,<c/> (e.g. what you would get by
> > > $a/element($b)). I've noticed that some people tend to understand
> > > Variable references in XQuery PathSteps this way.
> >
> > Yes, it's common enough for people to think that a variable holds a fragment
> > of an XPath expression that's treated as a macro and handled using textual
> > substitution. You see this a lot with people trying to write <xsl:sort
> > select="$sortkey"/> in XSLT. They've probably used other languages such as
> > shell scripts that use $ to introduce a macro variable.
> >
> > But I didn't recognize that particular error here!
> >
> 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.

-Michael Dyck

Received on Friday, 29 April 2005 06:17:43 UTC