XPath查询是从右到左解析的吗？

Question

This popular Stack Overflow question explained why CSS selectors are parsed right to left. XPath查询是否以相同方式评估？如果这取决于实现，我很高兴知道libxml2是如何做到的。

Answer 1

从右到左评估路径表达式毫无意义且几乎不可能：

/name1/name2/name3/name4

根据定义，这会选择作为任何name4元素的子元素的所有name3元素，这些元素是任何name2元素的子元素，该元素是名为{{1}的顶部元素的子元素}。

此链中的任何语句都依赖于下一个语句为真。因此，必要时，评估需要从name1到/name1再到/name1/name2，最后到/name1/name2/name3

这是在W3C XPath 1.0 specification ：

中明确指定的

  

相对位置路径由一个或多个序列组成   位置步骤由/分隔。 相对位置路径中的步骤   从左到右组成。每个步骤依次选择一个   相对于上下文节点的节点集。最初的一系列步骤   与以下步骤一起组成如下。最初的   步骤序列选择相对于上下文节点的一组节点。   该集合中的每个节点都用作以下的上下文节点   步骤即可。由该步骤标识的节点集合在一起。   由步骤的组成识别的节点集是这样的   联盟。例如，/name1/name2/name3/name4选择child::div/child::para   元素子元素的上下文节点的para元素子元素，   或换句话说，div元素para grandchildren   父母。

Answer 2

你应该仔细阅读你所引用的问题的接受答案。

CSS选择器从右到左作为特定场景的实现细节进行评估，其中浏览器具有单个元素并且正在尝试确定哪个选择器CSS样式表适用于它。浏览器在这种情况下评估从右到左的原因是因为可以更快地消除候选选择器。

CSS选择器没有固有的东西要求从右到左或从左到右进行评估。实际上，jQuery或querySelectorAll将从左到右进行评估，如答案所述。

换句话说：

1. 如果你有一个元素并且测试选择器是否匹配它，那么从右到左评估优化通常会更快;
2. 但如果您想要所有匹配元素，那么从左到右评估通常会更快。

方案1最适合您拥有样式元素（CSS）或XSL样式表的template match="??"（XPath），并且您需要测试大量选择器或XPath。当您使用单个选择器或XPath并且想要所有匹配元素时，场景2最适合，例如当您使用querySelectorAll或查询DOM时。

XPath表达式可能比CSS选择器复杂得多，因此可能存在XPath，其中从右到左的短路评估是不可能或不容易的，但从概念上讲，XSLT引擎当然可以尝试这样做。我不知道有没有。

要理解的最重要的事情是，无论是对CSS选择器还是XPath进行评估，它都必须给出相同的答案，好像在整个文档中从左到右进行评估树。所以你不需要 从左到右进行评估，但你必须表现得好像因为规范以这种方式定义它们。

Answer 3

当XSLT使用形式match =“a / b / c”的模式时，您有兴趣测试特定节点是否与模式匹配，并且最简单的方法是从右到左。但是当XPath使用select =“a / b / c”形式的表达式时，您有兴趣找到匹配的所有节点，最简单的方法是从左到右。但是，处理器没有义务（在任何一种情况下）以这种方式工作，并且可能存在特定处理器将表达式优化为其他形式的情况。例如，给定XPath表达式// a // b，处理器可能会将其重写为等效的// b [ancestor :: a]，这实际上是从右到左的评估。