Looking at the available axes in XSLT I had to find out that there is no sibling
axis which would be the union of preceding-sibling
and following-sibling
. To me this is a little surprising since I already wrote one answer (XSLT issue...CSV issue.?) in which this axis would have been helpful (although I only have about 10 answers so far). Of course, it is obvious that you can always solve the problem by using the union. So this axis is not really required. But it would be very handy every once in a while and like all the other axes IMHO it would make the code more readable and easier to maintain.
Does anybody know why this axis was left out? Is there maybe a non-obvious reason for this?
By the way: I found at least one issue on StackExchange with a warning about a potential performance degrade using the preceding-sibling
and following-sibling
axes. But I assume this is true for all the axes containing a substantial portion of the XML tree is used in a nested way. So the reason for omission could not have been due to performance.
Since there has been no activity with this question for a while I would like to answer it myself. Picking up one thought in the comments, it is, of course, hard to retrospectively say why the people responsible of the XSLT 1.0 specification omitted the
sibling
axis.One of the most conclusive reasons could have been related to the comments by @JLRiche and @MichaelKay: axis are supposed to go into a specific direction with respect to the reference node and it may be difficult to determine what the direction for
sibling
would be.In order to investigate this a little further I set up a test XSLT and a test input XML to check how the axes work (see further below) and in particular what the order of the nodes in the axes are. The result was surprising to me:
preceding-sibling
axes does not start at the node closest to the reference node but with node closest to the start of the document.following-sibling
does start at the reference node.This would actually allow to define
with the nodes in this set being continuously iterated from the beginning of the document to the end. There would be no "jump".
The suggested alternative
also works well and yields the same set in the same ordering. However, looking at an unfamiliar XSLT I would assume that a
sibling
axis would explain the logic better than using the parent-children construct.Interestingly, the fact that axes do not start at the node closest to the reference node but at the node closest the beginning of the document also applies to
preceding
andancestor
so for exampleancester::node[1]
does not return the parent of the node but the root node.The original motivation for me to ask the question was related to not having to repeat a lengthy
CONDITION
imposed on the attributes of the nodes, e.g. I did not want to writeHowever, since the expression above can be rewritten as
the disadvantage of having to use two axes instead of a
sibling
axis is not as bad as thought. Of course, in XSLT 2.0 this also works forSo, to answer my question: I don't think there is a good reason not to define a
sibling
axis. I guess nobody thought of it. :-)Test Setup
This XML test input
using this XSLT 2.0 sheet
will yield this output