[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
On 10/08/2011 04:15, Hank Ratzesberger wrote:
You're right that this is a highly subtle (=obscure and easily missed) feature of the XPath semantics.
This didn't change between XPath 1.0 and 2.0. Many people would have liked to change it, but backwards-compatibility ruled the day.
Re: [xsl] testing preceding sibling always evaluates true
Subject: Re: [xsl] testing preceding sibling always evaluates true From: Michael Kay <mike@xxxxxxxxxxxx> Date: Wed, 10 Aug 2011 10:13:34 +0100 |
On 10/08/2011 04:15, Hank Ratzesberger wrote:
Thank you Michael.And the following paragraph is also relevant to this discussion: in a FilterExpr, the items in a sequence are considered in their original order when evaluating the predicate; in an AxisStep, the nodes are considered in the order of the relevant axis.
I just received the 4th edition (it really is hardbound!) so I could check if anything had changed, but on p. 602 :
There are three kinds of expressions in XPath 2.0 whose result is guaranteed to be a sequence of nodes in document order...
o Any axis step (even and axis step like <preceding-sibling::*> that uses a reverse axis delivers its results in forwards document order)
But, reading on... p. 618
In effect, the predicate operator <[]> has a higher precedence (it binds more tightly) than the path operator </>
You're right that this is a highly subtle (=obscure and easily missed) feature of the XPath semantics.
This didn't change between XPath 1.0 and 2.0. Many people would have liked to change it, but backwards-compatibility ruled the day.
Michael Kay Saxonica
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] testing preceding sibling, Hank Ratzesberger | Thread | [xsl] Silent Auction Winners, Sam Wilmott |
AW: [xsl] nbsp fails transformation, Szabo, Patrick \(LNG | Date | Re: [xsl] nbsp fails transformation, Michael Kay |
Month |
Keywords