2

我一直在阅读XPath 3.1 的 W3 规范，对于大多数人来说阅读时间太长了（他们只会退出）。任何地方都有缩写规范吗？

我们的受众是我们系统的用户，他们需要编写 XPath 语句来提取他们需要的数据。他们不是程序员，他们是业务用户。他们希望在遇到困难时尽快找到满足其特定需求的解决方案。

更新：首先，我完全同意“内在张力”下方的@kjhughes 评论。而且我认为迈克尔提出了一个很好的观点，即快速指南应该是主要用途 - 删除边缘情况。并将注释减少到最低限度（同样没有边缘情况），但对示例是肯定的。

我们多年来一直使用的是本教程，它倾向于在简单性和教授所有基础知识之间取得很好的平衡。而且这个还不错。

但两者都没有讨论 XPath 3.1 或为 JSON 文件设计 XPath。有没有等价的东西。

例如，这是我仍在努力解决的三个基本项目：

  1. 基本查询的语法是什么。使用Southwind.json是否是“/Employees/Employee”来获取所有员工节点的列表（我无法在我的代码中成功加载 JSON 文件，所以我无法测试它）？
  2. 地图是否曾经从 XPath 查询/评估中返回？通过阅读本文，您似乎可以创建和使用它们，但您永远不会将它们作为查询的返回项目。
  3. 数组是否仅在 JSON 查询时返回？通过阅读本文，我认为情况就是如此。这只是映射到一个 JSON 数组 - 对吗？
4

2 回答 2

2

完整与简洁之间存在着内在的张力。

对于complete，官方规范无可替代：XML Path Language (XPath) 3.1。如果它看起来对您的需求来说过于广泛，那么您根本就不是目标受众。我们希望语言实现者有一个完整、精确的标准规范来构建库和工具。这是制定规范的全部意义所在。

为了简洁，您必然会牺牲完整性，但这里有一些可能适合作为概述或介绍的资源：

每个问题更新更新：

我们的受众是我们系统的用户，他们需要编写 XPath 语句来提取他们需要的数据。他们不是程序员，他们是业务用户。他们希望在遇到困难时尽快找到满足其特定需求的解决方案。

业务用户应该有一个适当的、特定于应用程序的 GUI，而不是期望编写原始的 XPath 或正则表达式或 SQL。

如果您坚持让您的业务用户编写 XPath，并且如果他们至少在技术上很复杂，那么您最好的选择是编写包含常用习语和示例的案例手册，他们可以尝试从中学习。补充有关 XPath 基础知识的演示文稿。

于 2020-07-16T20:22:28.060 回答
1

基本的问题是 XPath 已经成为一种相当大的语言，而且你构建的参考越简洁，它就越不可能包含你想问的每个问题的答案。对于您的具体问题：

基本查询的语法是什么。使用 Southwind.json 是 "/Employees/Employee"

我对数据集不熟悉。

地图是否曾经从 XPath 查询/评估中返回？

当然。返回地图的最简单查询是map{}.

数组是否仅在 JSON 查询时返回？

不，例如查询[1, 2, 3]返回一个数组，并且不涉及 JSON。

于 2020-07-17T17:29:17.700 回答