RE: (non) associativity slash operator

> I have two questions about the associativity of the slash operator.
> 
> 1. Why is the slash operator in XPath 2.0 defined in a 
> non-associative way?

I hadn't realised that position() and last() caused this problem - thanks
for pointing it out. However, we were aware of another situation that caused
"/" to be non-associative, namely the side-effects of node construction.

Imagine a source document 

<a>
  <b/>
  <b/>
  <b/>
</a>

with the <a> as the context node. Then consider the (XQuery-only) path
expression

  //b/../<d/>

If this is evaluated as (//b/..) / <d/> then only one <d> element is
created, because the lhs yields a single node. But if it is evaluated as
(//b) / (../<d/>) then three <d> elements are created, one for each c.

We decided not to do anything about this; the ability to create nodes within
an expression creates a few problems like this, and the optimizer simply has
to cope with them. Note that the same situation can occur in XSLT 2.0 if you
replace <d/> with a call to a function that creates new nodes. 

> So if I am correct then the slash 
> operation *is* actually associative in XPath 1.0, even though 
> its semantic definition seems otherwise. So that makes me 
> wonder about the reason why such a valuable algebraic 
> identity was dropped.

I believe you are correct that "/" is associative in XPath 1.0, certainly
Saxon assumes that it is. I think the generalization of path expressions to
allow function calls is worth this price. Of course, it's still fairly easy
for an optimizer to detect those cases where the path expression can be
rearranged in the same way as XPath 1.0.
> 
> 2. Is the slash operator left- or right-associative?
> 
> In XPath 1.0 the slash operator was left-associative because 
> of the way that the syntax was defined. 

The statement in the appendix that operators are evaluated from left to
right is intended to tell you that a/b/c means (a/b)/c, just as a-b+c means
(a-b)+c, but I agree that it could be more clearly expressed.

Michael Kay