作者在他的书中说,做了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 问题完全有效且不明显,但已经得到了很好的回答。