Result of // Use is Unexpected

Belch · September 5th, 2016, 11:54 AM

I have a node that is present in two places in my input XML, called "elementA".
The first instance has the value "aaa" and the second instance has the value "bbb".

If I set a variable called "thisVar" to "//elementA[1]" I would expect it to fetch the first elementA node that it finds (since //elementA returns two nodes, and the [1] predicate states I want node 1).

If I then use value-of select="$thisVar", it outputs the two elementA values concatenated, i.e. "aaa bbb".
There are also two nodes in $thisVar, both have the above value.

However, if I set the variable to simply be "//elementA" and then when calling the variable in the value-of, I use the predicate there instead, it works as expected.
I.e. using value-of select="$thisVar[1]" gets me a single node with the value "aaa".

I'm intrigued as to why the first solution doesn't produce the same result as the second solution.

Any info appreciated, thanks.

Martin Honnen · September 5th, 2016, 11:58 AM

Well, see https://www.w3.org/TR/xpath20/#abbrev, //elementA[1] is the same as /descendant-or-self::node()/elementA[1]. You might want descendant::elementA[1] or (//elementA)[1]

mhkay · September 5th, 2016, 12:31 PM

Yes, this is a well-known gotcha and is well-documented, including in the XPath 1.0 spec itself:

NOTE: The location path //para[1] does not mean the same as the location path /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.

Belch · September 6th, 2016, 07:04 AM

Thanks guys.
So the //elementA[1] expression is actually saying, get all elementA nodes that are the first child of their relevant parent, rather than doing the // first to get all nodes, and then applying the predicate?

Makes sense now I've read the documentation. Thanks for the assistance.