从头实现 JSON Schema 验证器 - 第2周

Source: Dev.to

背景

经过两周的阅读，我终于看完了 JSON Schema 规范（具体是 Core 和 Validation 规范）。我现在对 JSON Schema 验证器的实现有了相当清晰的概念，并对规范有了一些想法。

总体而言，作者做得非常出色——系统的几乎每一个细节都被提及：它应如何工作、实现应如何处理特定情况、收到的 schema 应该是什么样子，以及如果不符合要求该怎么办。

规范中的挑战

阅读规范时我遇到了一些困难。这可能是文档本身的歧义，也可能是我缺乏经验——因为这是我第一次系统地研读规范。主要问题包括：

• 对目标受众的歧义。
• 某些章节缺乏清晰度。

目标受众歧义

规范涉及三个不同的主体：

1. Schema 作者 – 编写 schema 以供验证器使用的人。
2. 验证器实现者 – 实现/编写验证器代码的人。
3. 规范扩展者 – 创建自定义关键字或词汇表的人。

文档很少指明某段落针对的是哪类受众。有时同一句话一开始面向一个群体，结尾却转向另一个群体。唯一能判断对象的方式是完整理解其上下文，这对新手来说相当困难。

具体的困惑点

• 词法作用域 vs. 动态作用域 – 解释不够清晰，导致难以把握两者的区别。
• 元模式（Meta‑schemas） – 我在上周的文章中已经详细讨论过，但规范的措辞仍让人困惑。
• 第 11 章中的 anyOf 示例 – 没有额外上下文，这个示例很难跟上。

如果能提供更多示例并使用更明确的表述，阅读规范会轻松很多。

有帮助的工具

我要特别感谢 Google 的 NotebookLM。我尝试了多种工具来帮助理解规范，NotebookLM 是最有帮助的。

计划实现范围

规范指出某些关键字和特性是强制的，而另一些是可选的。对于我的首次实现，我将：

• 仅支持 draft 2020‑12
• 不实现 $vocabulary 关键字
• 支持详细输出格式
• 不实现短路（short‑circuiting）
• 仅支持 format 关键字的注解功能
• 不实现对使用 schema 父级或祖先基 URI 的 JSON 指针的解引用（参见 Core 规范第 9.2.1 节）
• 不进行远程 schema 拉取

目标是尽可能降低难度，完成第一个完整功能的验证器，因为这是我第一次尝试实现符合规范的软件系统。

未来工作

一旦拥有一个基本且完整功能的验证器，我可能会考虑加入：

• 更多草案 – 通过具备弹性的架构设计，后续添加新草案应当相对直接。
• 短路（short‑circuiting） – 如果能够以符合规范的方式实现。
• format 关键字的断言 – 如果我觉得学习价值或实现过程有趣的话。