为何相同表达式在XPath 3.0可用但XQuery 3.0无法生效？

我之前也碰到过类似的问题，核心原因是XPath和XQuery对节点序列的处理逻辑有细微差异，咱们一步步来解决：

问题根源：text()的处理方式不同 #

你原表达式里用了contains(text(), 'All Water System Contacts')来定位<p>元素。

在Oxygen执行XPath时，哪怕text()返回的是单个文本节点，XPath 3.0会自动把这个节点序列转换成一个字符串（拼接所有文本内容），所以contains能正常匹配。

但多数XQuery处理器的类型检查更严格：contains()的第一个参数要求是单个字符串，而不是节点序列。哪怕text()只返回一个节点，处理器也会把它当成序列处理，不会自动转成字符串，导致匹配失败。

快速修复：用.替代text() #

把contains(text(), ...)改成contains(., ...)就行。.代表当前节点的完整字符串值（会自动拼接所有子文本节点的内容），这个写法在XPath和XQuery里的行为完全一致：

//table[tbody/tr/th/p[contains(., 'All Water System Contacts')]]/tbody/tr[3]/td[1]

用这个修正后的表达式测试你的XML，就能正确返回目标<td>元素：

<td align="center">AC - Administrative Contact - GENERAL MANAGER </td>

其他可能的坑点 #

1. 上下文节点不一致
   在Oxygen里执行XPath时，你可能选中了某个子节点作为起始上下文。但在XQuery中，你需要确保是针对整个文档查询。比如如果是从文件读取，要显式绑定文档：

let $doc := doc("你的XML文件路径.xml")
return $doc//table[tbody/tr/th/p[contains(., 'All Water System Contacts')]]/tbody/tr[3]/td[1]

如果跳过这一步，有些XQuery处理器可能无法默认定位到整个文档，导致返回空结果。

2. 处理器严格程度差异
   Oxygen通常用Saxon作为XPath/XQuery处理器，它的规则相对灵活。如果你用的是其他XQuery引擎，可能对类型转换的要求更严格。而用.的写法能彻底避开这个问题，因为它明确使用了节点的字符串值。

内容的提问来源于stack exchange，提问作者Серж Грицкив