6538 2009-02-06 14:07:10 +0000 [FS] Inconsistent following-sibling behaviour of attribute nodes 2009-02-17 01:52:17 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 nick jmdyck public-qt-comments oldest_to_newest 23498 0 nick 2009-02-06 14:07:10 +0000 I believe the behaviour of following-sibling is in the language and formal semantics specifications, particularly with respect to starting on an attribute node. 3.2.1.1 of the language spec states: "if the context node is an attribute node, the following-sibling axis is empty" 4.2.1.1 of the formal semantics states: [following-sibling:: NodeTest]Axis == [let $e := . return $e/parent::node()/child:: NodeTest [.>>$e]]Expr This normalization doesn't reflect the same behaviour when starting on an attribute node. Further, if this normalization were changed to match the language spec it cause the normalization of the following:: axis to be different when starting on an attribute node, as this is normalized as: [following:: NodeTest]Axis == [ancestor-or-self::node()/following-sibling::node()/descendant-or-self:: NodeTest]Expr But the language spec does not define an empty sequence when starting on an attribute node for the following:: axis. 23567 1 jmdyck 2009-02-08 07:03:53 +0000 I agree, FS's normalization rule for following-sibling is incorrect. I propose we fix it by adding a 'where' clause to the right-hand side: [ let $e := . where fn:not($e/self::attribute()) return $e/parent::node()/child:: NodeTest [.>>$e] ]_Expr And thanks for the heads-up re the following:: axis, although I believe the danger is not that it would mistakenly yield an empty sequence, but rather that it would yield a sequence that is missing the descendants of the attribute's parent. We could add them in explicitly, but I think that would be fairly ugly. Instead, I suggest we go back to the definition: the 'following' axis contains all nodes that are descendants of the root of the tree in which the context node is found, are not descendants of the context node, and occur after the context node in document order and express it thusly: [ following:: NodeTest ]_Axis == [ let $e := . return fn:root() / descendant:: NodeTest [. >> $e] except $e / descendant::node() ]_Expr 23568 2 jmdyck 2009-02-08 07:05:48 +0000 The XQuery test suite doesn't appear to have any tests for applying the following-sibling axis to an attribute node. I suggest something like: <foo a='1' b='2' c='3'> <bar>4</bar> <bar>5</bar> <bar>6</bar> </foo>/@a/following-sibling::node() yielding empty. Similarly for preceding-sibling (but using @c, on the off-chance some implementation thinks attributes a and b are preceding-siblings of attribute c). 23593 3 nick 2009-02-09 12:32:41 +0000 Those two normalizations looks reasonable to me. I've tried them out in our implementation and they both seem to fix the tests which originally showed the problem (axes102 and axes108 in the XSLT test suite) without breaking any previously working tests in that or XQTS. 23634 4 jmdyck 2009-02-11 06:55:02 +0000 At their meeting this morning, the joint WGs approved the solution proposed in Comment #1. Consequently, I'm marking this issue resolved-FIXED. If you agree with this resolution, please mark the issue CLOSED. 23781 5 jmdyck 2009-02-17 01:52:17 +0000 This issue has been entered as FS erratum E060, and the proposed fixes have been committed to the source files for the next edition of the FS document.