作者在他的书中说，做了Document Order解释：
换句话说，文档顺序只是指节点在XML文档中出现的顺序。例如，当您处理包含其他元素的元素时，顺序是毫无疑问的，但是当您处理同一级别的元素时 - 文档顺序指定它们应该按照它们在原始XML文档。
这里还有一件事需要了解，文档顺序 - 属性节点没有任何特殊顺序，即使是文档顺序。
现在我的问题是 -
为什么不需要属性的顺序？
“当你处理包含其他元素的元素时，对顺序毫无疑问，” - 为什么？
答案 0 :(得分：1)
要详细说明之前的答案并回复第一条评论，我认为这一切都围绕着层次结构。如果元素包含其他元素，则顺序很明显，因为存在层次结构。
在以下示例中，a按文档顺序排在b之前。
<a>
<b/>
</a>
在以下示例中，b和c是兄弟姐妹（两者都在同一级别; a的子级）。对于兄弟姐妹来说文档顺序不是很明显，但c在文档顺序中位于b之前。
<a>
<c/>
<b/>
</a>
如果结构复杂，这会让人感到困惑。例如，在以下文档d中，b在文档顺序中位于d之前，即使b位于层次结构树的下方（它是c的子项兄弟<a>
<c>
<d/>
</c>
<b/>
</a>
）。
/*/@*[1]不需要属性的顺序，因为它们不代表层次结构。他们只是在描述/进一步定义元素。想想元数据。他们唯一的文件排序是元素属性在任何元素子元素之前。属性的相对顺序取决于实现。
例如，如果您在以下文档中使用XPath <foo b="x" a="x"/>
：
a您可以获取b属性或{{1}}属性，具体取决于实现如何对属性进行排序。
答案 1 :(得分：0)
“当你处理包含其他元素的元素时，对顺序毫无疑问，” - 为什么？
嗯，显然有一个问题，因为你刚问过它。只是由于某种原因，作者认为答案是显而易见的。答案是，如果A是B的祖先，则A按文档顺序排在B之前。
为什么不需要属性的顺序？
XML中的设计原则是，如果订单很重要，则不应使用属性。这与对象建模的语义有关：属性表示独立和正交的对象的属性。像形容词一样：说一些大红色的盒子就像说它是一个红色的大盒子一样。如果不是（如“大白鲨”），则形容词不是名词的真正属性限定词，不应该用XML作为属性建模。
答案 2 :(得分：0)
为了支持流式传输，文档顺序是“显而易见”的选择，“毫无疑问”，并且在大多数情况下对 XML 数据最有用。
但是，考虑到 XML 文档可以表示为树结构，并且 XPath 对该树进行操作，因此 XPath 结果的呈现顺序远非显而易见。树遍历是一个有趣的主题，有很多变化，例如预购、有序、先呼吸和其他几种。 （参见维基百科和“树遍历”的其他来源）。
所以虽然作者的描述是正确的，但他掩盖了很多事情。特别是关于在树上运行的 XPath，OP 问题完全有效且不明显，但已经得到了很好的回答。