User's Guide description of following:: vs following-sibling:: (needs an edit ?)
Under Axes, The User's Guide currently reads:
following : Returns nodes following each of the previously matched nodes matching predicate
following-sibling : Same as following axis, but also include current node
(and there's an analogous description of the difference between preceding:: and preceding-sibling::)
Experimentally, however, the real difference within each of these pairs seems to have more to do with something like:
- all following/previous nodes, vs
- following/previous siblings only
For example, running a query on the User's Guide itself,
/*/Axes/following::@type!=emptyfinds 306 matches, whereas/*/Axes/following-sibling::@type!=emptyfinds only the 2 sibling sections: Set Operations and Predicates
Perhaps an edit to the User's Guide is needed ? The behaviour itself seems intuitively right and useful.
2 Posted by ComplexPoint on 30 Nov, 2012 06:02 AM
For the moment, I've amended my copy to read:
Support Staff 3 Posted by Jesse Grosjean on 30 Nov, 2012 04:28 PM
Good catch, I've updated the user's guide to match.
4 Posted by ComplexPoint on 30 Nov, 2012 05:03 PM
Was there perhaps a plan for two additional axes ?
following-sibling-or-self::preceding-sibling-or-self::(I can see that they would be useful, and symmetrical with the other
or-selfaxes)Support Staff 5 Posted by Jesse Grosjean on 30 Nov, 2012 05:14 PM
No, at least not for the moment. I'm just trying to copy what Xpath provides, and I figure if they didn't need it then neither to do we...
http://www.w3schools.com/xpath/xpath_axes.asp
Our course we could add. But for now you should be able to get the same behavior with two paths (one to self and one to self following) and then union those two paths.
6 Posted by ComplexPoint on 30 Nov, 2012 05:56 PM
Makes sense – standards and a kind of elegant parsimony both sound good :-)
( I had just wondered whether the original text had been displaced from elsewhere )