| 互联网工程任务组 | A. Wright，编辑 |
| 互联网草案 | |
| 预期状态：信息 | H. Andrews，编辑 |
| 到期时间：2018 年 9 月 20 日 | Cloudflare, Inc. |
| 2018 年 3 月 19 日 |
JSON Schema: 用于描述 JSON 文档的媒体类型
draft-handrews-json-schema-01
JSON Schema 定义了媒体类型 "application/schema+json"，这是一种基于 JSON 的格式，用于描述 JSON 数据的结构。JSON Schema 断言 JSON 文档应该是什么样子，以及从中提取信息的方式，以及如何与之交互。 "application/schema-instance+json" 媒体类型提供了更丰富的与 "application/schema+json" 的集成功能，超出了 "application/json" 文档所能提供的功能。
此草案的问题列表可以在 <https://github.com/json-schema-org/json-schema-spec/issues> 中找到。
有关更多信息，请参阅 <https://json-schema.fullstack.org.cn/>。
要提供反馈，请使用此问题跟踪器，主页上列出的通信方式，或电子邮件联系文档编辑。
本互联网草案完全符合 BCP 78 和 BCP 79 的规定提交。
互联网草案是互联网工程任务组 (IETF) 的工作文档。请注意，其他团体也可能将工作文档作为互联网草案发布。当前互联网草案列表位于 http://datatracker.ietf.org/drafts/current/。
互联网草案是有效期最多为六个月的草案文档，并且可以随时更新、替换或被其他文档废弃。不适宜使用互联网草案作为参考材料，或引用它们，除非作为“正在进行的工作”。
本互联网草案将于 2018 年 9 月 20 日到期。
版权所有 (c) 2018 IETF 信托和被识别为文档作者的人员。保留所有权利。
本文件受 BCP 78 和 IETF 信托的 IETF 文件法律条款 (http://trustee.ietf.org/license-info) 约束，这些条款在本文件发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包含简化 BSD 许可证文本，如信托法律条款第 4.e 节所述，并且按简化 BSD 许可证中所述提供，不提供任何保证。
JSON Schema 是一种 JSON 媒体类型，用于定义 JSON 数据的结构。JSON Schema 旨在定义 JSON 数据的验证、文档、超链接导航和交互控制。
本规范定义了 JSON Schema 的核心术语和机制，包括通过引用指向另一个 JSON Schema、反引用 JSON Schema 引用以及指定所使用的词汇表。
其他规范定义了执行关于验证、链接、注释、导航和交互的断言的词汇表。
本文件中的关键词“必须”、“禁止”、“必需”、“应该”、“不应该”、“推荐”、“可以”和“可选”的解释方式如 RFC 2119 [RFC2119] 中所述。
本文件中的术语“JSON”、“JSON 文本”、“JSON 值”、“成员”、“元素”、“对象”、“数组”、“数字”、“字符串”、“布尔值”、“真”、“假”和“空”的解释方式如 RFC 7159 [RFC7159] 中所述。
本文件提出了一种新的媒体类型 "application/schema+json"，用于标识描述 JSON 数据的 JSON Schema。它还提出了一种可选的媒体类型 "application/schema-instance+json"，以提供额外的集成功能。JSON Schema 本身就是 JSON 文档。本规范以及相关规范定义了关键字，允许作者以多种方式描述 JSON 数据。
JSON Schema 描述了 JSON 文档的结构（例如，必需属性和长度限制）。应用程序可以使用此信息来验证实例（检查约束是否满足），或通知接口收集用户输入，以便满足约束。
验证行为和关键字在 单独的文档 [json-schema-validation] 中指定。
JSON Schema 可以使用信息对实例进行注释，只要实例验证通过包含注释的 Schema 对象及其所有父 Schema 对象即可。
详细的注释行为以及一小部分基本注释关键字在 验证规范 [json-schema-validation] 中定义。
JSON Hyper-Schema 描述了 JSON 文档的超文本结构。这包括从实例到其他资源的链接关系、将实例解释为多媒体数据以及使用 API 所需的提交数据。
超 Schema 行为和关键字在 单独的文档 [json-hyper-schema] 中指定。
JSON 文档是由 application/json 媒体类型描述的信息资源（一系列字节）。
在 JSON Schema 中，由于它定义的数据模型，“JSON 文档”、“JSON 文本”和“JSON 值”这些术语可以互换。
JSON Schema 仅在 JSON 文档上定义。但是，任何可以解析为 JSON Schema 数据模型或根据 JSON Schema 数据模型进行处理的文档或内存结构都可以针对 JSON Schema 进行解释，包括像 CBOR [RFC7049] 这样的媒体类型。
应用 Schema 的 JSON 文档称为“实例”。
JSON Schema 根据数据模型来解释文档。根据此数据模型解释的 JSON 值称为“实例”。
实例具有六种基本类型之一，并且根据类型具有范围内的可能值
空格和格式问题，包括数字的不同词法表示（在数据模型中相等），因此不在 JSON Schema 的范围内。希望处理这种词法表示差异的 JSON Schema 词汇表 [vocabulary] 应该定义关键字以精确地解释数据模型中的格式化字符串，而不是依赖于原始 JSON 表示的 Unicode 字符可用。
由于对象不能具有两个键相同的属性，因此对于试图在单个对象中定义两个键（“成员”产生式）相同（“字符串”产生式）的 JSON 文档的行为是未定义的。
请注意，JSON Schema 词汇表可以自由地定义自己的扩展类型系统。这与这里定义的核心数据模型类型不应该混淆。例如，“整数”是词汇表可以定义为关键字值的合理类型，但数据模型不区分整数和其他数字。
JSON Schema 旨在与 "application/json" 文档以及使用 "+json" 结构化语法后缀的媒体类型完全配合使用。
每个媒体类型都定义了一些用于处理 Schema 的有用功能，即媒体类型参数以及 URI 片段标识符的语法和语义。这些功能分别在内容协商和计算实例中特定位置的 URI 时很有用。
本规范定义了 "application/schema-instance+json" 媒体类型，以便实例作者能够充分利用参数和片段标识符来实现这些目的。
当且仅当两个 JSON 实例具有相同的类型并且根据数据模型具有相同的值时，它们才被认为是相等的。具体来说，这意味着
这个定义隐含着数组必须具有相同的长度，对象必须具有相同的成员数量，对象中的属性是无序的，无法定义具有相同键的多个属性，并且仅仅的格式差异（缩进、逗号位置、尾随零）无关紧要。
JSON Schema 文档，简称 schema，是一个用于描述实例的 JSON 文档。Schema 本身被解释为一个实例，但 SHOULD 始终被赋予媒体类型“application/schema+json”，而不是“application/schema-instance+json”。“application/schema+json”媒体类型被定义为提供“application/schema-instance+json”提供的媒体类型参数和片段标识符语法和语义的超集。
JSON Schema MUST 是一个对象或一个布尔值。
应用于实例的对象属性称为关键字或 Schema 关键字。从广义上讲，关键字可以归为以下两类之一或两者
关键字可以属于任一类或两类。扩展关键字，即在本文档及其配套文档之外定义的关键字，可以自由地定义其他行为。
布尔值 Schema 值“true”和“false”是微不足道的断言，无论实例值如何，它们始终返回自身。例如，就验证词汇表而言，布尔值 Schema 等效于以下行为
JSON Schema MAY 包含不是 Schema 关键字的属性。未知关键字 SHOULD 被忽略。
空 Schema 是一个没有属性的 JSON Schema，或者只有未知属性。
JSON Schema 词汇表是为特定目的定义的一组关键字。词汇表指定其关键字的含义为断言、注释和/或任何词汇表定义的关键字类别。本文档的两个配套标准分别定义了一个词汇表：一个用于实例验证，另一个用于超媒体注释。词汇表是 JSON Schema 媒体类型中可扩展性的主要机制。
词汇表可以由任何实体定义。如果词汇表旨在广泛使用，并且可能与其他词汇表组合使用，那么词汇表作者 SHOULD 注意避免关键字名称冲突。JSON Schema 没有提供任何正式的命名空间系统，但也没有限制关键字名称，允许使用任意数量的命名空间方法。
词汇表可以相互构建，例如通过根据来自另一个词汇表的关键字的行为来定义其关键字的行为，或者通过使用来自另一个词汇表的关键字，但具有受限或扩展的允许值集。并非所有此类词汇表重用都会导致新的词汇表与它构建的词汇表兼容。词汇表作者 SHOULD 清楚地记录预期哪些级别的兼容性（如果有的话）。
本身描述 Schema 的 Schema 称为元 Schema。元 Schema 用于验证 JSON Schema 并指定它正在使用哪个词汇表。 [CREF1]目前，每个 Schema 只能指定一个元 Schema，这意味着为了使用多个词汇表，必须编写一个包含所有词汇表的元 Schema。超 Schema 元 Schema 就是一个例子，因为它包含验证词汇表和超媒体词汇表。
根 Schema 是包含所讨论的整个 JSON 文档的 Schema。
某些关键字本身就采用 Schema，允许 JSON Schema 嵌套
{
"title": "root",
"items": {
"title": "array item"
}
}
在本示例文档中，标题为“array item”的 Schema 是一个子 Schema，而标题为“root”的 Schema 是根 Schema。
与根 Schema 一样，子 Schema 也是一个对象或一个布尔值。
根据 [RFC6839] 的第 3.1 节，为任何 +json 媒体类型指定的片段标识符的语法和语义 SHOULD 与“application/json”中指定的语法和语义相同。（在发布本文档时，没有为“application/json”定义片段标识语法。）
此外，“application/schema+json”媒体类型支持两种片段标识符结构：普通名称和 JSON 指针。“application/schema-instance+json”媒体类型支持一种片段标识符结构：JSON 指针。
JSON 指针用作 URI 片段标识符的用法在 RFC 6901 [RFC6901] 中进行了描述。对于支持两种片段标识符语法的“application/schema+json”，包括空字符串在内的与 JSON 指针语法匹配的片段标识符 MUST 解释为 JSON 指针片段标识符。
根据 W3C 的 片段标识符最佳实践 [W3C.WD-fragid-best-practices-20121025]，“application/schema+json”中的普通名称片段标识符保留用于引用本地命名的 Schema。所有与 JSON 指针语法不匹配的片段标识符 MUST 解释为普通名称片段标识符。
在“application/schema+json”文档中定义和引用普通名称片段标识符在 "$id" 关键字 [id-keyword] 部分中指定。
实例可以是 JSON [RFC7159] 中定义的任何有效 JSON 值。JSON Schema 不会对类型施加任何限制：JSON Schema 可以描述任何 JSON 值，包括例如 null。
JSON Schema 与编程语言无关，并支持数据模型中描述的全部范围的值。但是，请注意，某些语言和 JSON 解析器可能无法在内存中表示 JSON 可描述的全部范围的值。
某些编程语言和解析器对浮点数使用不同的内部表示，而不是对整数使用不同的内部表示。
为了保持一致性，整数 JSON 数字 SHOULD NOT 以小数部分编码。
实现 MAY 对 JSON Schema 定义额外的关键字。除了明确的协议外，Schema 作者 SHALL NOT 预期这些额外的关键字得到同行实现的支持。实现 SHOULD 忽略它们不支持的关键字。
鼓励 JSON Schema 扩展的作者编写自己的元 Schema，这些元 Schema 使用“allOf”扩展现有的元 Schema。这个扩展的元 Schema SHOULD 使用“$schema”关键字引用，以允许工具遵循正确的行为。
请注意，元 Schema 的递归性质要求在扩展的元 Schema 中重新定义递归关键字，如 JSON 超 Schema 元 Schema 中所示。
“$schema”关键字既用作 JSON Schema 版本标识符，也用作资源的位置，该资源本身是一个 JSON Schema，描述了为此特定版本编写的任何 Schema。
此关键字的值 MUST 是一个 URI [RFC3986]（包含方案），并且此 URI MUST 被规范化。当前 Schema MUST 对此 URI 标识的元 Schema 有效。
如果此 URI 标识可检索的资源，则该资源 SHOULD 是“application/schema+json”媒体类型。
“$schema”关键字 SHOULD 在根 Schema 中使用。它 MUST NOT 出现在子 Schema 中。
此属性的值在其他文档和由其他方定义。JSON Schema 实现 SHOULD 实施对当前和以前发布的 JSON Schema 词汇表的草案的支持，只要认为合理。
为了区分庞大生态系统中的 Schema，Schema 通过 URI [RFC3986] 标识，并且可以通过指定其 URI 来嵌入对其他 Schema 的引用。
RFC 3986 第 5.1 节 [RFC3986] 定义了如何确定文档的默认基准 URI。
非正式地说，Schema 的初始基准 URI 是找到它的 URI，或者如果未知，则是一个合适的替代 URI。
“$id”关键字定义了 Schema 的 URI，以及解决 Schema 中其他 URI 引用所依据的基准 URI。子 Schema 的“$id”相对于其父 Schema 的基准 URI 进行解析。如果父级没有使用“$id”设置显式基准，则基准 URI 是整个文档的基准 URI，如 RFC 3986 第 5 节 [RFC3986] 所定义。
如果存在，此关键字的值 MUST 是一个字符串，并且 MUST 代表一个有效的 URI 引用 [RFC3986]。此值 SHOULD 被规范化，并且 SHOULD NOT 是空的片段 <#> 或空的字符串 <>。
JSON Schema 文档的根 Schema SHOULD 包含一个“$id”关键字，其中包含一个 绝对 URI [RFC3986]（包含方案，但没有片段），或者包含此绝对 URI 但具有空片段。
当“$id”设置基准 URI 时，可以使用从该位置开始的 JSON 指针片段来标识包含该“$id”及其所有子 Schema 的对象。即使是进一步更改基准 URI 的子 Schema 也是如此。因此，单个子 Schema 可以通过多个 URI 访问，每个 URI 由子 Schema 或父级中声明的基准 URI 以及标识从声明基准的 Schema 对象到被标识的子 Schema 的路径的 JSON 指针片段组成。本节 8.2.4 中展示了这些示例。
使用 JSON 指针片段需要了解 Schema 的结构。在编写旨在提供可重用 Schema 的 Schema 文档时，最好使用不与任何特定结构位置绑定的普通名称片段。这样，即使子 Schema 被重新定位，也不需要更新 JSON 指针引用。
要指定此类子 Schema 标识符，将“$id”关键字设置为具有普通名称片段（而不是 JSON 指针片段）的 URI 引用。此值 MUST 以指定片段的数字符号（“#”）开头，然后是一个字母（[A-Za-z]），后面可以跟任意数量的字母、数字（[0-9]）、连字符（“-”）、下划线（“_”）、冒号（“:”）或句点（“.”）。
使用不是空白或不遵循普通名称语法的片段作为“$id”的效果未定义。 [CREF3]如何解释包含其他组件的片段的“$id”URI 引用？有两种情况：当其他组件与当前基准 URI 匹配时，以及当它们更改基准 URI 时。
考虑以下 Schema，它显示了“$id”用于标识根 Schema、更改子 Schema 的基准 URI 以及为子 Schema 分配普通名称片段
{
"$id": "http://example.com/root.json",
"definitions": {
"A": { "$id": "#foo" },
"B": {
"$id": "other.json",
"definitions": {
"X": { "$id": "#bar" },
"Y": { "$id": "t/inner.json" }
}
},
"C": {
"$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f"
}
}
}
以下 URI 编码的 JSON 指针 [RFC6901]（相对于根 Schema）处的 Schema 具有以下基准 URI，并且可以根据第 5 节中列出的任何 URI 标识
“$ref”关键字用于引用 Schema，并提供通过自引用验证递归结构的能力。
具有“$ref”属性的 Schema 对象 MUST 被解释为“$ref”引用。 “$ref”属性的值 MUST 为 URI 引用。 针对当前 URI 基准进行解析，它标识要使用的 Schema 的 URI。 “$ref”对象中的所有其他属性 MUST 被忽略。
URI 不是网络定位器，只是一个标识符。 如果 URI 是可网络寻址的 URL，则 Schema 不必从地址下载，并且实现 SHOULD NOT 假设它们在遇到可网络寻址的 URI 时应该执行网络操作。
Schema MUST NOT 对 Schema 陷入无限循环。 例如，如果两个 Schema “#alice” 和 “#bob” 都具有引用另一个 Schema 的“allOf”属性，则朴素的验证器可能会陷入无限递归循环，试图验证实例。 Schema SHOULD NOT 使用这样的无限递归嵌套； 行为是未定义的。
使用 URI 来标识远程 Schema 不一定意味着任何内容都被下载，而是 JSON Schema 实现 SHOULD 提前了解它们将使用的 Schema 以及标识它们的 URI。
当 Schema 被下载时，例如由一个在运行时不知道要下载哪个 Schema 的通用用户代理下载，请参见超媒体的使用 [hypermedia]。
实现 SHOULD 能够将任意 URI 与任意 Schema 相关联，或根据验证器对 Schema 的信任程度自动关联 Schema 的“$id”给定的 URI。 此类 URI 和 Schema 可以在处理实例之前提供给实现，或者在处理 Schema 文档时在其中进行标记，从而生成第 8.2.4 节中所示的关联。
Schema MAY（并且很可能）具有多个 URI，但 URI 无法标识多个 Schema。 当多个 Schema 尝试标识为同一个 URI 时，验证器 SHOULD 提出错误条件。
Schema 可以通过任何赋予它们的 URI 来标识，包括 JSON 指针或其直接由“$id”给定的 URI。 在所有情况下，解引用“$ref”引用都涉及首先根据 RFC 3986 [RFC3986] 将其值解析为针对当前基本 URI 的 URI 引用。
如果生成的 URI 标识当前文档中的 Schema，或标识已提供给实现的另一个 Schema 文档中的 Schema，则 SHOULD 自动使用该 Schema。
例如，考虑以下 Schema
{
"$id": "http://example.net/root.json",
"items": {
"type": "array",
"items": { "$ref": "#item" }
},
"definitions": {
"single": {
"$id": "#item",
"type": "object",
"additionalProperties": { "$ref": "other.json" }
}
}
}
当实现遇到 <#/definitions/single> Schema 时，它会将“$id”URI 引用解析为针对当前基本 URI 的 <http://example.net/root.json#item>。
当实现随后在 <#/items> Schema 中查找时，它会遇到 <#item> 引用，并将其解析为 <http://example.net/root.json#item>，它已经在这个同一个文档中定义，因此可以自动使用。
当实现遇到对“other.json”的引用时，它会将其解析为 <http://example.net/other.json>，该引用未在此文档中定义。 如果实现中已提供具有该标识符的 Schema，则也可以自动使用它。 [CREF4]当引用 Schema 未知时，实现应该怎么做？ 在哪些情况下允许自动网络解引用？ 同源策略？ 用户可配置选项？ 在由超 Schema 描述的不断发展的 API 的情况下，预计新的 Schema 将动态添加到系统中，因此绝对要求预加载 Schema 文档不可行。
此关键字保留用于 Schema 作者对 Schema 阅读者或维护者的注释。 此关键字的值 MUST 为字符串。 实现 MUST NOT 将此字符串呈现给最终用户。 用于编辑 Schema 的工具 SHOULD 支持显示和编辑此关键字。 此关键字的值 MAY 在针对开发人员的调试或错误输出中使用，这些开发人员使用 Schema。 Schema 词汇表 SHOULD 允许在包含词汇表关键字的任何对象中使用“$comment”。 实现 MAY 假设“$comment”是被允许的，除非词汇表明确禁止它。 词汇表 MUST NOT 指定“$comment”除了本规范中描述的任何其他效果。 将其他媒体类型或编程语言转换为 application/schema+json 以及从 application/schema+json 转换的工具 MAY 选择将该媒体类型或编程语言的本机注释转换为或从“$comment”值转换。 当同时存在本机注释和“$comment”属性时，此类转换的行为是依赖于实现的。 实现 SHOULD 将“$comment”与未知扩展关键字相同对待。 它们 MAY 在处理过程中的任何时候剥离“$comment”值。 特别是，这允许在部署 Schema 的大小是一个问题时缩短 Schema。 实现 MUST NOT 基于“$comment”属性的存在、不存在或内容采取任何其他操作。
JSON 已被 HTTP 服务器广泛用于自动化 API 和机器人。 本节描述了在与支持媒体类型和 Web 链接 [RFC8288] 的协议一起使用时，如何以更 RESTful 的方式增强对 JSON 文档的处理。
RECOMMENDED，由 Schema 描述的实例使用“describedby”链接关系提供指向可下载 JSON Schema 的链接，如 链接数据协议 1.0，第 8.1 节 [W3C.REC-ldp-20150226] 所定义。
在 HTTP 中，此类链接可以使用 Link 标头 [RFC8288] 附加到任何响应。 这样的标头的示例将是
Link: <http://example.com/my-hyper-schema#>; rel="describedby"
媒体类型 MAY 允许“schema”媒体类型参数，这使 HTTP 服务器能够基于 Schema 执行内容类型协商。 媒体类型参数 MUST 为一个空格分隔的 URI 列表（即相对引用无效）。
使用媒体类型 application/schema-instance+json 时，MUST 提供“schema”参数。
Schema URI 是不透明的，SHOULD NOT 自动被解引用。 如果实现不理解提供的 Schema 的语义，则实现可以改为遵循“describedby”链接（如果有），这些链接可能提供有关如何处理 Schema 的信息。 由于“schema”不一定指向网络位置，因此“describedby”关系用于链接到可下载的 Schema。 但是，为了简单起见，Schema 作者应尽可能使这些 URI 指向同一个资源。
在 HTTP 中，媒体类型参数将被发送到 Content-Type 标头中
Content-Type: application/json;
schema="http://example.com/my-hyper-schema#"
多个 Schema 是空格分隔的
Content-Type: application/json;
schema="http://example.com/alice http://example.com/bob"
[CREF5]本段假定我们可以注册“schema”链接关系。 我们现在是否应该改为指定类似“tag:json-schema.org,2017:schema”的内容？ HTTP 也可以在 Link 中发送“schema”，尽管如果这完全替换了媒体类型参数，这可能会影响媒体类型语义和内容类型协商
Link: </alice>;rel="schema", </bob>;rel="schema"
当用于网络上的超媒体系统时，HTTP [RFC7231] 通常是用于分发 Schema 的协议选择。 如果有问题的客户端比必要时更频繁地从网络上拉取 Schema，而实际上可以将 Schema 缓存很长一段时间，则可能会给服务器维护者带来问题。
HTTP 服务器 SHOULD 在 JSON Schema 上设置长期缓存标头。 HTTP 客户端 SHOULD 遵守缓存标头，并且不要在它们的有效期内重新请求文档。 分布式系统 SHOULD 利用共享缓存和/或缓存代理。
User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
客户端 SHOULD 设置或预先附加特定于 JSON Schema 实现或软件产品的 User-Agent 标头。 由于符号按重要性降序排列，因此 JSON Schema 库名称/版本应位于更通用的 HTTP 库名称（如果有）之前。 例如
客户端 SHOULD 能够使用“From”标头发出请求，以便服务器操作员可以联系可能存在问题的脚本的所有者。
Schema 和实例都是 JSON 值。 因此，RFC 7159 [RFC7159] 中定义的所有安全注意事项都适用。
实例和 Schema 通常由不受信任的第三方编写，并在公共互联网服务器上部署。 验证器应注意，解析和验证 Schema 不应消耗过多的系统资源。 验证器 MUST NOT 陷入无限循环。
服务器 MUST 确保恶意方无法通过上传具有预先存在或非常相似的“$id”的 Schema 来更改现有 Schema 的功能。
各个 JSON Schema 词汇表也可能具有自己的安全注意事项。 有关更多信息，请参阅各自的规范。
Schema 作者应注意“$comment”内容，因为恶意实现可能会违反规范将其显示给最终用户，或者如果预期这种行为，则无法将其剥离。
恶意 Schema 作者可能会在“$comment”中放置可执行代码或其他危险材料。 实现 MUST NOT 解析或基于“$comment”内容采取其他行动。
JSON Schema 的拟议 MIME 媒体类型定义如下
需要 JSON Schema 特定媒体类型的 JSON Schema 实例的拟议 MIME 媒体类型定义如下
| [RFC2119] | Bradner, S.，"RFC 中用于指示需求级别的关键词"，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [RFC3986] | Berners-Lee, T.，Fielding, R. 和 L. Masinter，"统一资源标识符 (URI)：通用语法"，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月。 |
| [RFC6839] | Hansen, T. 和 A. Melnikov，"媒体类型结构化语法后缀"，RFC 6839，DOI 10.17487/RFC6839，2013 年 1 月。 |
| [RFC6901] | Bryan, P.，Zyp, K. 和 M. Nottingham，"JavaScript 对象符号 (JSON) 指针"，RFC 6901，DOI 10.17487/RFC6901，2013 年 4 月。 |
| [RFC7159] | Bray, T.，"JavaScript 对象符号 (JSON) 数据交换格式"，RFC 7159，DOI 10.17487/RFC7159，2014 年 3 月。 |
| [W3C.REC-ldp-20150226] | Speicher, S.，Arwe, J. 和 A. Malhotra，"链接数据平台 1.0"，万维网联盟推荐 REC-ldp-20150226，2015 年 2 月。 |
| [RFC7049] | Bormann, C. 和 P. Hoffman，"简洁二进制对象表示 (CBOR)"，RFC 7049，DOI 10.17487/RFC7049，2013 年 10 月。 |
| [RFC7231] | Fielding, R. 和 J. Reschke，"超文本传输协议 (HTTP/1.1)：语义和内容"，RFC 7231，DOI 10.17487/RFC7231，2014 年 6 月。 |
| [RFC8288] | Nottingham, M.，"网页链接"，RFC 8288，DOI 10.17487/RFC8288，2017 年 10 月。 |
| [W3C.WD-fragid-best-practices-20121025] | Tennison, J.，"片段标识符和媒体类型定义的最佳实践"，万维网联盟 LastCall WD-fragid-best-practices-20121025，2012 年 10 月。 |
| [json-schema-validation] | Wright, A.，Andrews, H. 和 G. Luff，"JSON Schema 验证：用于 JSON 结构验证的词汇"，互联网草案 draft-handrews-json-schema-validation-01，2017 年 11 月。 |
| [json-hyper-schema] | Andrews, H. 和 A. Wright，"JSON 超级模式：用于 JSON 超媒体注释的词汇"，互联网草案 draft-handrews-json-schema-hyperschema-01，2017 年 11 月。 |
感谢 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 对 JSON Schema 初始草案的贡献。
感谢 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch 和 Dave Finlay 对文档的提交和修补。