It would be great to have a 'clean' discussion about this... the comments on this issue is cumbersome, and the mailing list for Jaxen appears to have been unused for half-a-decade...
But, in my head, the issue is 'clearl', yet I don't seem to be able to communicate it effectively.... and I think you have the same 'clarity' in your head... which is fine, but hear me out...
... and I think I will start by asking you to consider three different specific points, in order:
1. I agree, XML spec does not define a particular order for Attributes, in fact, it says: Note that the order of attribute specifications in a start-tag or empty-element tag is not significant. The XML InfoSet specification also says the order of Attributes is not defined to be part of the InfoSet.
2. XPath specification does define that a document order exists for Attributes, and that the order is 'implementation specific'. - Section 5 defines the 'Document Order' including: "The relative order of namespace nodes is implementation-dependent. The relative order of attribute nodes is implementation-dependent." One very important question as it relates to this bug, (and I will expand on this later) is "what is the 'implementation'"? Further, the order of these values, the Namespaces and Attributes, are 'exposed' in the XPath specification as the attribute:: and namespace:: axes. The XPath spec defines all axes to be either in document-order, or reverse-document-order. There is no explicit exception for attribute:: or namespace::. Further, the document order is not allowed to change during the evaluation of a query. The implication is that: a) there is a document order; b) it is implementation-dependent for attribute:: and namespace:: and c) it is not allowed to change during the evaluation of an expression.
3. The Jaxen 'specification' defines an abstraction layer between the XPath 'engine' and the document 'model'. The engine can work on any model that is defined using the Jaxen 'Navigator'. The documentation for 'Navigator' says: "There is a method to obtain a java.util.Iterator, for each axis specified by XPath.".
The only way to make Jaxen work in all cases is for the Navigator implementation to be consistent with all three specifications... XML, XPath, and Jaxen.
Now, back to the question of 'implementation-dependant'. Who 'owns' the implementation. Jaxen's documentation is not as 'rigourous' or 'formal' as a w3c specification, but, there is a clear implication that "Jaxen is an engine", There is a document model (with implementations for DOM, XOM, etc.), and the Navigator defines the 'interface' between the engine and the model.
The issue at hand (JAXEN 215) is really about who owns the 'document order'. In my head it is clear that the document order is 'owned' by the document model, and is 'exposed' by the Navigator.
In your head it seems that the document order is owned by the document model for everything except the attribute and the namespace axes, where Jaxen unilaterally redefines the order to be something else.
There is no specification that makes Jaxen reorder those axes. On the contrary, Jaxen 'clearly' delegates the order of the axes to the Navigator.
So, the symptoms of this contradiction between the Navigator concept and the Jaxen reordering is things like the following should be 'obvious', but they break (using an XPath 'pseudocode'):
element.getAttributes().item(0) == XPath.evaluate("@*", element)
element.getNamespacesInScope().get(0) == XPath.evaluate("namespace::*", element);
and so on....
Other issues are things like new artificial differences between the :
XPath.selectSingleNode("@") and XPath.selectNodes("@")
I want to point out a special 'marketing' angle for Jaxen that the engine can be applied to non-XML models too - as long as they can expose the implementation in a way that conforms to the Navigator (this is something that I have done with Jaxen a couple of times already.... -apart from JDOM - by the way).
So, apart from pointing out the incongruence you have introduced by 'stealing' ownership of 'document order', I guess I can put together a demonstration of it.... which I have already done a number of times in this discussion, but perhaps I will do it with something other than JDOM....
Oh, by the way, it was me who put together the test case for #221.....