Re: Variable references in path expressions

>
> 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.
>
I have a problem with this interpretation. The lhs of "/" iterates each item
to establish the focus for evaluation of each item in the rhs expression. Yes ?
Now if each item is a QName, then this should be interpreted as a
Name test. No ?

If I interprete you correctly, then,

let
 $book := <book><title>blah</title><author>foo</author></book>,
 $fields := (xs:QName("title"),xs:QName("author"))
 return $book/$fields

would return
xs:QName("title"),xs:QName("author")

and not
<title>blah</title><author>foo</author>

While the variables are bound prior to the path expression,
the evaluation of "/" can interprete $b to make
the path expression in a meaningful and consistent
manner.

I need to understand how

$book/$fields
returning xs:QName("title"),xs:QName("author")

can be seen to be useful as a path expression.

It this is so then the semantics of the path expression
as defined must then otherwise been changed. The
definition should appropriately define the above
behaviour.

Quote : XQuery 3.2 Path Expressions
[Definition: A path expression can be used to locate nodes within trees.
A path expression consists of a series of one or more steps, separated
by "/" or "//", and optionally beginning with "/" or "//".]


> In a conventional path expression such as a/following-sibling::*, how would
> I convert following-sibling::* into a QName?
>
You can't, syntactically, this is identified by the parser as a Wildcard
and a Wildcard token cannot be represented as an atomic type nor
a node in a sequence. Maybe it can be cast into a string but this will
will have significant impact on the overall grammar.

However, a variable is definitely bound to a sequence; you can
run through its items and produce a sequence of QName before
processing "/". I don't see why this is not implementable
to align with the objective of a path expression.