与其他浏览器相比，Edge 中 Xpath Function name() 的大小写敏感性不一致
Case sensitivity of Xpath Function name() is inconsistent in Edge compared to other browsers
问题：
在Edge中使用[name() = "SomeValue"]时，如果要匹配的"SomeValue"包含大写字母，则不会return个节点。即使那些大写字母与节点名称完全匹配。
示例：
我创建了 this JSFiddle which exhibits problem. It uses two XML strings, both a subset of the books.xml sample on MSDN, where the first has capitalized node names and the second I have modified to use lowercase node names. Fiddle with cleaner code.
当前结果：
运行 Edge 中的 fiddle，搜索 [name() = "catalog"] 时会看到，其中 "catalog" 是任何大小写混合的，只有当搜索词完全小写时，XPath 才会匹配节点.请注意，匹配节点的大小写无关紧要，如果节点名称是驼峰式、全大写或全部小写，术语 "catalog" 将匹配该节点。
Edge 将匹配所有这三个节点：
<Catalog/><CATALOG/><catalog/>
当 运行 在另一个浏览器中相同时（我测试过 Firefox、Chrome 和 Opera），搜索词必须与节点名称大小写完全匹配，这就是我对 XPath 的期望操作。在上面的三个节点名称中，这些浏览器仅在使用 [name() = "Catalog"]
时匹配 <Catalog/>
预期结果：
我希望 Edge 的行为与其他浏览器相同，因为 text() 等其他功能在 Edge 中不会以这种方式运行，这使得它更加不一致。这也显示在 JSFiddle 中。
我期望相同行为的另一个原因是，我测试的所有浏览器都只支持 XPath 1.0，因此应该没有区别。
总结：
这是Edge的缺陷吗？ / 这是标准允许的吗？如果不允许，我可以向 Microsoft 提交错误报告。如果标准允许，我是否只需要考虑浏览器差异？
附加信息
使用 jQuery 支持现有软件，并寻找不需要额外第三方软件的解决方案。
XPath 1.0 是在特定数据模型上定义的，这与 HTML DOM 并不完全相同。尤其是 HTML5 DOM 是在 XPath 1.0 冻结多年后定义的。这意味着任何在 HTML5 DOM 上实现 XPath 1.0 的人都必须决定如何将 HTML5 DOM 映射到 XPath 数据模型。如果不同的供应商以不同的方式进行这种映射，那将是非常不幸的，但这实际上并不违反任何标准。在定义此映射时要做出的关键决定之一是如何处理 HTML5 不区分大小写而 XPath 1.0 区分大小写的事实。
这里的根本问题是您使用 HTML5 DOM 来保存不是 HTML 的东西。这是一个坏主意，因为 HTML5 努力将您的内容弯曲为 HTML5 模型，这可能会以令人惊讶的方式破坏您的数据。为这个数据创建一个 XML DOM 会好得多。
此外，使用谓词 [name()='SomeValue'] 无论如何都是不好的做法，因为 XPath 1.0 不保证 name() 函数结果中的命名空间前缀。如果数据在命名空间中，则使用 self::SomeValue 或 self::hh:SomeValue 会好得多（尽管将 HTML5 映射到 XPath 数据模型的命名空间实例会引发另一组潜在问题.)
建议：使用 Saxon-JS 作为您的 XPath 引擎。这样 (a) 您将获得对 XPath 3.0 而不是 1.0 的支持，并且 (b) 您在每个浏览器上使用相同的 XPath 引擎，因此它将提供跨浏览器的兼容行为。
问题：
在Edge中使用[name() = "SomeValue"]时，如果要匹配的"SomeValue"包含大写字母，则不会return个节点。即使那些大写字母与节点名称完全匹配。
示例：
我创建了 this JSFiddle which exhibits problem. It uses two XML strings, both a subset of the books.xml sample on MSDN, where the first has capitalized node names and the second I have modified to use lowercase node names. Fiddle with cleaner code.
当前结果：
运行 Edge 中的 fiddle，搜索 [name() = "catalog"] 时会看到，其中 "catalog" 是任何大小写混合的，只有当搜索词完全小写时，XPath 才会匹配节点.请注意，匹配节点的大小写无关紧要，如果节点名称是驼峰式、全大写或全部小写，术语 "catalog" 将匹配该节点。
Edge 将匹配所有这三个节点：
<Catalog/><CATALOG/><catalog/>
当 运行 在另一个浏览器中相同时（我测试过 Firefox、Chrome 和 Opera），搜索词必须与节点名称大小写完全匹配，这就是我对 XPath 的期望操作。在上面的三个节点名称中，这些浏览器仅在使用 [name() = "Catalog"]
<Catalog/>
预期结果：
我希望 Edge 的行为与其他浏览器相同，因为 text() 等其他功能在 Edge 中不会以这种方式运行，这使得它更加不一致。这也显示在 JSFiddle 中。
我期望相同行为的另一个原因是，我测试的所有浏览器都只支持 XPath 1.0，因此应该没有区别。
总结：
这是Edge的缺陷吗？ / 这是标准允许的吗？如果不允许，我可以向 Microsoft 提交错误报告。如果标准允许，我是否只需要考虑浏览器差异？
附加信息
使用 jQuery 支持现有软件，并寻找不需要额外第三方软件的解决方案。
XPath 1.0 是在特定数据模型上定义的，这与 HTML DOM 并不完全相同。尤其是 HTML5 DOM 是在 XPath 1.0 冻结多年后定义的。这意味着任何在 HTML5 DOM 上实现 XPath 1.0 的人都必须决定如何将 HTML5 DOM 映射到 XPath 数据模型。如果不同的供应商以不同的方式进行这种映射，那将是非常不幸的，但这实际上并不违反任何标准。在定义此映射时要做出的关键决定之一是如何处理 HTML5 不区分大小写而 XPath 1.0 区分大小写的事实。
这里的根本问题是您使用 HTML5 DOM 来保存不是 HTML 的东西。这是一个坏主意，因为 HTML5 努力将您的内容弯曲为 HTML5 模型，这可能会以令人惊讶的方式破坏您的数据。为这个数据创建一个 XML DOM 会好得多。
此外，使用谓词 [name()='SomeValue'] 无论如何都是不好的做法，因为 XPath 1.0 不保证 name() 函数结果中的命名空间前缀。如果数据在命名空间中，则使用 self::SomeValue 或 self::hh:SomeValue 会好得多（尽管将 HTML5 映射到 XPath 数据模型的命名空间实例会引发另一组潜在问题.)
建议：使用 Saxon-JS 作为您的 XPath 引擎。这样 (a) 您将获得对 XPath 3.0 而不是 1.0 的支持，并且 (b) 您在每个浏览器上使用相同的 XPath 引擎，因此它将提供跨浏览器的兼容行为。