Steps when the context value contains multiple nodes

[michaelhkay]

We have two conflicting statements in the spec.

§4.6.4 says: "The step expression S is equivalent to ./S. Thus, if the context value is a sequence containing multiple nodes, the semantics of a step expression are equivalent to a path expression in which the step is always applied to a single node."

§4.6.5 says: "When the context value for evaluation of a step includes multiple nodes, the step is evaluated separately for each of those nodes, and the results are combined without reordering."

I'm not sure which is intended: does S means. / S, or . ! S?

[ChristianGruen]

I'm not sure which is intended: does S means. / S, or . ! S?

I think it should/must be ./S (§4.6.4).

[ChristianGruen]

In principle, expressions with variable references and context value references should always yield the same results:

let $a := <x><a/><a/></x>/a
return $a/..,

<x><a/><a/></x>/a
-> ./..

[michaelhkay]

The question here is when there is no explicit "/".

let $a := <x><a id="1"><b id="2"/></x>
return $a -> (x/b, x/a) -> @id

Certainly ./@id returns (1,2) and .!@id returns (2,1), the question is, what does @id on its own return?

[ChristianGruen]

Certainly ./@id returns (1,2) and .!@id returns (2,1), the question is, what does @id on its own return?

id='1' followed byid='2'.

It always seemed obvious to us to treat step and ./step identically. Your question indicates I should think about the actual reasons:

I guess it is because path expressions always return duplicate-free and ordered results, no matter whether they start with ./ or not. Assume you bind a node set to the context value before you apply an arbitrary path expression on it: it would be pretty counterintuitive if ./a/b and a/b returned different results.

Or think of collection('abc')//xyz: users should get the same result if the collection is bound to the context value.

[michaelhkay]

Remember that the RHS of "/" can be any expression. Even when the context value is a single item, (a,b) and ./(a,b) can return different results. We don't simply define the semantics of (a,b) as being equivalent to ./(a,b)

[michaelhkay]

Or think of collection('abc')//xyz: users should get the same result if the collection is bound to the context value.

For better or worse, the results of collection('abc') are not necessarily in document order; it's the // operator that forces them to be sorted.

[ChristianGruen]

Remember that the RHS of "/" can be any expression. Even when the context value is a single item, (a,b) and ./(a,b) can return different results. We don't simply define the semantics of (a,b) as being equivalent to ./(a,b)

Correct; it would be (./a, ./b) (as defined in §4.6.4).

Probably the current conflict would simply be resolved if the questionable section was dropped from §4.6.5 – or do you think there is something else that would need to be clarified? It seems to be the wrong section anyway (Predicates within Steps).

[ruv]

@michaelhkay wrote:

Even when the context value is a single item, (a,b) and ./(a,b) can return different results.

To illustrate this, I have prepared two examples in XPath 3.1.

Example 1:

<x><a>1</a><b>2</b></x> [  (b,a) => head() = "2" ]

It returns the node x. According to the XPath grammar, (b,a) can be treated as a path expression consisting of a single step.

Example 2:

<x><a>1</a><b>2</b></x> [ ./(b,a) => head() = "2" ]

It returns the empty sequence. Thus, (b,a) cannot be replaced with ./(b,a) in the first example.

An excerpt from §4.6.4 (current version)

The step expression S is equivalent to ./S. Thus, if the context value is a sequence containing multiple nodes, the semantics of a step expression are equivalent to a path expression in which the step is always applied to a single node. The following description therefore explains the semantics for the case where the context value is a single node, called the context node.
Note:
The equivalence of a step S to the path expression ./S means that the resulting node sequence is returned in document order.

Given that S is any step expression, this equivalence seems incorrect.

In the first glance, S seems equivalent to .!S. But this is also incorrect, because ./ S and ./ .!S produce different results in my example.

[ChristianGruen]

Given that S is any step expression, this equivalence seems incorrect.

Note that (a, b) is not a single step expression, but an expression that consists of two step expressions. If S and ./S are defined to be equivalent, it does not apply to S1, S2 and ./(S1 S2).

[michaelhkay]

Given that S is any step expression, this equivalence seems incorrect.

I think that by "step expression", it means "an instance of the production AxisStep.

In this sense, (b, a) is not a step expression.

Unfortunately this loose use of language to refer to expression types is common throughout the spec. For example the term "arithmetic expression" is used, without definition, to mean "a non-trivial instance of AdditiveExpr or MultiplicativeExpr, that is, an instance that includes an arithmetic operator". It's a tricky problem to solve, but we should try, especially in cases like this where it really isn't obvious.

We do have formal definitions of some of the terms used to describe types of expression (for example "filter expression" and "static function call") but this is the exception rather than the rule.

[ruv]

Agreed, if "step expression" is AxisStep than the equivalence holds. But 4.6.4 is about any StepExpr.

And the part:

if the context value is a sequence containing multiple nodes, the semantics of a step expression are equivalent to a path expression in which the step is always applied to a single node. The following description therefore explains the semantics for the case where the context value is a single node, called the context node.

seems correct for any step expression.

---

Regarding whether (b,a) is a StepExpr.

If I understand correctly, in XPath grammar:

• ParenthesizedExpr is a PrimaryExpr
• PrimaryExpr is a PostfixExpr
• PostfixExpr is a StepExpr

Thus, ParenthesizedExpr is a StepExpr.

Also:

• StepExpr is a RelativePathExpr
• RelativePathExpr is a PathExpr

Of course, ParenthesizedExpr can contain zero or more PathExpr.

[michaelhkay]

Regarding whether (b,a) is a StepExpr

Yes, that's the problem I was trying to explain: 3 is an "otherwise expression", in the sense that it is an instance of the production OtherwiseExpr. We freely use terms like "otherwise expression" hoping they will be understood to mean "an expression directly using the otherwise operator", but we never formalise this. The problem is particularly acute with terms like path expression, filter expression, step expression that don't relate directly to production names in the grammar.

I think that the phrase Step Expression is intended to mean an instance of the production AxisStep, but it's entirely possible that it is misused to mean "any expression used as an operand of the "/" operator".