I might have talked nonsense here:
ancestor-or-self is a forward axis and the position of nodes in a forward axis is defined in terms of document order:
See the Xpath Rec: 2.4 Predicates
[...] Thus, the ancestor, ancestor-or-self, preceding, and preceding-sibling axes are reverse axes; all other axes are forward axes. [...] The proximity position of a member of a node-set with respect to an axis is defined to be the position of the node in the node-set ordered in document order if the axis is a forward axis and ordered in reverse document order if the axis is a reverse axis. The first position is 1.
First of all, ancestor-or-self is a *reverse-axis* so the "proximity position" is in reverse document order. Second, I now think that this "proximity position" is only relevant with regard to positional predicate filtering, not with regard to the order of nodes in the xpath result node set. E.g.
root.xpath("/a/b/c/ancestor-or-self::*[position()=1]") [<Element c at 266870>] root.xpath("/a/b/c/ancestor-or-self::*[position()=2]") [<Element b at 2668d0>] root.xpath("/a/b/c/ancestor-or-self::*[position()=3]") [<Element a at 266930>]
As you can see, position numbering indeed follows reverse document order here. Third, I *think* that, as the result of the xpath expression "/a/b/c/ancestor-or-self::*" is a node-set, the order of nodes in the nodeset is an implementation detail; document order might be a good choice to have consistent results. Clarifications welcome. Holger -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01