RE: implementer's diversity


I think the section of the specification that's most directly relevant to
your question is 2.3.4: "Abbreviated syntax":

>  3. // is short for /descendant-or-self::node()/. For example,
>  //para is short for /descendant-or-self::node()/child::para
>  and so will select any para element in the document  (even
>  a para element that is a document element will be selected
>  by //para since the document element node is a child of the
>  root node); div1//para is short for
>  div1/descendant-or-self::node()/child::para
>  and so will select all para descendants of div1 children.

>  Note that the path expression //para[1] does not mean the same
>  as the path expression /descendant::para[1]. The latter selects the
>  first descendant para element; the former selects all descendant
>  para elements that are the first para children of their parents."

The second paragraph provides an answer if you accept the premise and are
willing to argue by analogy, since you can replace "para" with "*" and
restate the last sentence as, "the former selects all descendant elements
that are the first children of their parents."

If you require a more theoretical explanation (and I'm not sure if I'm the
best person to do this, since I get a headache every time I try to read the
paragraph you're citing below!), we can write out the full, unabbreviated
version of //*[1] as

       /descendant-or-self::node()/child::*[ position() = 1 ]

The E1 in the paragraph you're citing corresponds to
/descendant-or-self::node(). In this case this is evaluated only once (as
you say), resulting in a node sequence consisting of every node in the
document, including the document node itself. We then iterate through this
sequence, isolating each individual node in turn as the context item and
evaluating the E2 part of the expression (child::*[position()=1]) against
that item. The key concept here is that the context item is evaluated
multiple times.

If I'm not stating this with full, technical accuracy, I'm sure that one of
the language-lawyer experts in the working group would be happy to take a
whack at it!


> -----Original Message-----
> From: []
> Sent: Thursday, May 30, 2002 6:40 AM
> To:
> Cc:
> Subject: Re: implementer's diversity
> Howard
> I think there's some ambiguity in the spec and I believe OpenLink is
> actually producing the correct answer (*).  Let's see if we can
> reason through
> this...
> You claim that //*[1] should return 3 things: the entire document, the
> first child of the top-level element, and the first child of each other
> non-leaf node.  Your assertion is, essentially, that //* should give the
> parent of every child possible, which I think is incorrect.
> Let me pull a couple of points out of the XQuery spec that I think are
> relevant (from
> Section, item 2 talks about the [1] predicate:
>    If the value of the predicate expression is an atomic value
>    of a numeric type, the predicate truth value is true if and
>    only if the value of the predicate expression is equal to the
>    context position.
> I think we can agree that [1] is a numeric atom :)
> So then we get true iff 1 == "the context position"
> This is defined, I think, back up at in the second bullet item,
> which says:
>    The context position is the position of the context item
>    within the sequence of items currently being processed. It
>    changes whenever the context item changes. Its value is always
>    an integer greater than zero. The context position is returned
>    by the expression position(). When an expression E1/E2, E1[E2],
>    or E1 sortby E2 is evaluated, the context position in the inner
>    focus for an evaluation of E2 is the position of the context item
>    in the sequence obtained by evaluating E1.
> So from this I take it that the context item is evaluated only once.  In
> that evaluation, //* gives us the root node.  Therefore, the correct
> answer is the first child of that root node, i.e. the <bib> element (and
> its children).
> I don't see anything in the XQuery spec that would call for a repeated
> re-evaluation of the context item and I don't see how to derive the answer
> you got without such a repeated re-evaluation.  Am I missing something?
> Perhaps it's time to discuss creation of a set of "interoperability" test
> cases for XQuery, to complement the W3C Use Cases?
> --Alan Wexelblat
> OpenLink Software
> (*) Note that I do work for OpenLink so I have a vested interest in the
> answer, but if this discussion comes out differently we are happy to
> change our implementation to interoperate.

Received on Thursday, 30 May 2002 12:42:20 UTC