作者在他的书中，在进行文档顺序解释时说：
换句话说，文档顺序只是指节点在XML文档中出现的顺序。例如，当您处理包含其他元素的元素时，顺序是毫无疑问的，但当您处理同一级别的元素（同级元素）时，文档顺序指定它们应该按照原始XML文档中的顺序进行排序。
关于文档顺序，还有一点需要了解——属性节点没有任何特殊的顺序，即使是文档顺序。
现在我的问题是-
-
为什么不需要属性的顺序
-
"当你处理包含其他元素的元素时，顺序是毫无疑问的，"-为什么
-
为了详细说明前面的答案并回应第一条评论，我认为这一切都围绕着层次结构。如果一个元素包含其他元素，则顺序是显而易见的，因为存在层次结构。
在以下示例中，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>
不需要属性的顺序，因为它们不代表层次结构。他们只是在描述/进一步定义元素。想想元数据。他们真正拥有的唯一文档顺序是元素属性位于任何元素子元素之前。属性的相对顺序取决于实现。
例如，如果在以下文档中使用XPath /*/@*[1]：
<foo b="x" a="x"/>
根据实现对属性的排序方式，可以获得a属性或b属性。
"当你处理包含其他元素的元素时，顺序是毫无疑问的，"——为什么？
很明显，有一个问题，因为你刚刚问过。只是作者出于某种原因，认为答案很明显。答案是，如果A是B的祖先，那么A按文档顺序在B之前。
为什么不需要属性的顺序？
XML中的一个设计原则是，如果顺序很重要，就不应该使用属性。这与对象建模的语义有关：属性表示对象的独立和正交属性。就像形容词一样：说某事是一个红色的大盒子和说它是一个红的大盒子的意思是一样的。如果不是（如"大白鲨"），则形容词不是名词的真正定语限定词，不应在XML中建模为属性。
为了支持流式传输，文档顺序是"明显的"；选择；毫无疑问"；，并且在大多数情况下是对XML数据最有用的。
然而，考虑到XML文档可以表示为树结构，并且XPath在该树上进行操作，XPath结果的呈现顺序还远远不清楚。树遍历是一个有趣的主题，有很多变化，例如预购、按顺序、呼吸优先等等。（参见"树遍历"的wikipedia和其他来源）。
因此，尽管作者对wrt XML的描述是正确的，但他掩盖了很多事情。特别是关于在树上操作的XPath，OP问题是完全有效的，并不明显，但已经得到了很好的回答。