用于描述 JSON 文档结构和含义的 JSON 媒体类型
draft-zyp-json-schema-01

摘要

JSON（JavaScript 对象表示法）模式定义了媒体类型 application/schema+json，它是一种基于 JSON 的格式，用于定义 JSON 数据的结构。JSON 模式为给定应用程序所需的 JSON 数据以及如何与之交互提供了一个契约。JSON 模式旨在定义 JSON 数据的验证、文档、超链接导航和交互控制。

本备忘录的状态

本互联网草案根据 BCP 78 和 BCP 79 的规定提交给 IETF。

互联网草案是互联网工程任务组 (IETF) 及其领域和工作组的工作文档。请注意，其他团体也可能将工作文档作为互联网草案分发。

互联网草案是有效期最长为六个月的草案文档，可能随时更新、替换或被其他文档废止。将互联网草案用作参考材料或引用它们（除了“正在进行的工作”）是不合适的。

可以在 http://www.ietf.org/ietf/1id-abstracts.txt 访问当前互联网草案列表。

可以在 http://www.ietf.org/shadow.html 访问互联网草案影子目录列表。

本互联网草案将于 2010 年 6 月 8 日过期。

版权声明

版权所有 (c) 2009 IETF 信托和被识别为文档作者的人员。保留所有权利。

本文件受 BCP 78 和 IETF 信托的 IETF 文档相关法律条款 (http://trustee.ietf.org/license-info) 约束，该条款在本文件发布之日生效。请仔细阅读这些文档，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包含简化 BSD 许可证文本（如信托法律条款第 4.e 节中所述），并且按 BSD 许可证中所述提供，不提供任何担保。

目录

1.  简介
2.  约定
3.  概述
    3.1.  术语
    3.2.  设计注意事项
4.  模式/实例关联
    4.1.  自描述模式
5.  核心模式定义
    5.1.  类型
    5.2.  属性
    5.3.  项目
    5.4.  可选
    5.5.  additionalProperties
    5.6.  需要
    5.7.  最小值
    5.8.  最大值
    5.9.  minimumCanEqual
    5.10.  maximumCanEqual
    5.11.  minItems
    5.12.  maxItems
    5.13.  模式
    5.14.  最大长度
    5.15.  最小长度
    5.16.  枚举
    5.17.  标题
    5.18.  描述
    5.19.  格式
    5.20.  内容编码
    5.21.  默认值
    5.22.  maxDecimal
    5.23.  禁止
    5.24.  扩展
6.  超级模式
    6.1.  链接
        6.1.1.  链接描述对象
    6.2.  fragmentResolution
        6.2.1.  点分隔片段解析
    6.3.  根
    6.4.  只读
    6.5.  pathStart
    6.6.  媒体类型
    6.7.  备用
7.  安全注意事项
8.  IANA 注意事项
    8.1.  链接关系注册表
9.  参考资料
    9.1.  规范性参考资料
    9.2.  信息性参考资料
附录 A.  更改日志
附录 B.  未解决的问题

1.  简介

JSON（JavaScript 对象表示法）模式是一种 JSON 媒体类型，用于定义 JSON 数据的结构。JSON 模式为给定应用程序所需的 JSON 数据以及如何与之交互提供了一个契约。JSON 模式旨在定义 JSON 数据的验证、文档、超链接导航和交互控制。

2.  约定

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“可能”和“可选”的解释如 RFC 2119 中所述。

3.  概述

JSON 模式定义了媒体类型 application/schema+json，用于描述其他 JSON 文档的结构。JSON 模式基于 JSON，并包含用于描述 JSON 文档结构的工具，包括允许的值、描述以及解释与其他资源的关系。

JSON 模式格式组织成几个独立的定义。第一个定义是核心模式规范。该定义主要关注描述 JSON 结构并指定结构中有效元素。第二个定义是超级模式规范，旨在定义结构中可以解释为超链接的元素。超级模式构建在 JSON 模式之上，以描述其他 JSON 文档的超链接结构。这允许用户代理能够根据其模式成功导航 JSON 文档。

累积地，JSON 模式充当元文档，可用于定义属性值的所需类型和约束，以及定义属性值的含义，以描述资源并确定表示中的超链接。

描述产品的 JSON 模式示例可能如下所示

{
  "name":"Product",
  "properties":{
    "id":{
      "type":"number",
      "description":"Product identifier"
    },
    "name":{
      "description":"Name of the product",
      "type":"string"
    },
    "price":{
      "type": "number",
      "minimum":0
    },
    "tags":{
      "optional":true,
      "type":"array",
      "items":{
         "type":"string"
      }
    }
  },
  "links":[
    {
      "rel":"full",
      "href":"{id}"
    },
    {
      "rel":"comments",
      "href":"comments/?id={id}"
    }
  ]
}

此模式定义了实例 JSON 文档的属性及其必需属性（id、name 和 price）以及可选属性（tags）。这也定义了实例 JSON 文档的链接关系。

3.1.  术语

对于本规范，模式将用于表示 JSON 模式定义，实例是指模式将要描述和验证的 JSON 对象或数组。

3.2.  设计注意事项

JSON 模式媒体类型不尝试规定包含数据的 JSON 表示的结构，而是提供了一种独立的格式，用于灵活地传达如何解释和验证 JSON 表示，以便用户代理能够正确理解可接受的结构并从 JSON 文档中推断超链接信息。本规范不定义协议。底层协议（例如 HTTP）应充分定义客户端-服务器接口的语义、与 JSON 表示链接的资源表示的检索以及这些资源的修改。该格式的目标是充分描述 JSON 结构，以便人们可以使用现有协议从各种利用 REST 架构的服务中利用现有 JSON 表示中可用的现有信息。

4.  模式/实例关联

JSON 模式实例通过“describedby”关系与其模式相关联，其中模式被定义为该关系的目标。实例表示可以是 application/json 媒体类型或任何其他子类型。因此，规定实例表示应如何指定与模式的关系超出了本文件的规范范围（因为本文件专门定义了 JSON 模式媒体类型，而不是其他类型），但建议实例指定其模式，以便用户代理能够解释实例表示，并且消息可以保留自描述特征，避免对实例数据的带外信息的需要。建议使用两种方法来声明与描述 JSON 实例（或实例集合）结构的含义的模式的关系。SHOULD 使用名为“describedby”的 MIME 类型参数或具有“describedby”关系的链接头。

Content-Type: application/json;
              describedby=http://json.com/my-hyper-schema

或者，如果内容通过提供头的协议（例如 HTTP）传输，则可以使用链接头

Link: <http://json.com/my-hyper-schema>; rel="describedby"

实例 MAY 指定多个模式，以指示适用于数据的全部模式。实例数据可能具有多个定义其的模式（实例数据应对于这些模式有效）。或者，如果文档是实例的集合，则集合可能包含来自不同模式的实例。当集合包含异构实例时，MAY 在模式中指定 pathStart 属性，以区分应为集合中的每个项目应用哪个模式。

4.1.  自描述模式

JSON 模式本身是模式模式的实例。可以在 https://json-schema.fullstack.org.cn/schema 中找到核心 JSON 模式的自描述 JSON 模式，超级模式自描述可以在：https://json-schema.fullstack.org.cn/hyper-schema 中找到。协议中使用的所有具有媒体类型定义的模式 SHOULD 包含一个 MIME 参数，该参数引用自描述超级模式或扩展此超级模式的另一个模式

Content-Type: application/json;
              describedby=http://www.json-schema.org/hyper-schema

5.  核心模式定义

JSON 模式是一个 JSON 对象，它定义了实例的各种属性，并定义了它的使用和有效值。JSON 模式是一个具有模式属性属性的 JSON 对象。以下是 JSON 模式的语法

JSON 模式定义示例可能如下所示

{"description":"A person",
 "type":"object",

 "properties":
  {"name": {"type":"string"},
   "age" : {"type":"integer",
     "maximum":125}}
}

JSON 模式对象可能具有以下任何属性，称为模式属性（所有属性都是可选的）

5.1.  类型

联合类型定义 - 一个具有两个或多个项目的数组，表示类型定义的联合。数组中的每个项目可能是一个简单的类型定义或一个模式。如果实例值与数组中类型定义之一的类型相同，或者如果它通过数组中的某个模式有效，则实例值有效。例如，要指示字符串或数字有效：{"type":["string","number"]}

简单类型定义 - 一个字符串，表示原始类型或简单类型。以下是可接受的字符串

字符串 - 值必须是字符串。

数字 - 值必须是数字，允许使用浮点数。

整数 - 值必须是整数，不允许使用浮点数。这是数字类型的子集。

布尔值 - 值必须是布尔值。

对象 - 值必须是对象。

数组 - 值必须是数组。

空 - 值必须为空。请注意，这主要是为了能够使用联合类型来定义可空性。

任何 - 值可以是任何类型，包括空。如果未定义属性或不在此列表中，则任何类型的值都是可接受的。其他类型值可用于自定义目的，但规范实现的最小验证器可以在未知类型值上允许任何实例值。

5.2.  属性

这应该是一个对象类型定义，它是一个具有属性定义的对象，这些属性定义对应于实例对象属性。当实例值是一个对象时，实例对象的属性值必须符合此对象中的属性定义。在此对象中，每个属性定义的值应该是一个模式，并且属性的名称应该是它定义的实例属性的名称。

5.3.  项目

这应该是一个模式或模式数组。当这是一个对象/模式并且实例值为数组时，数组中的所有项都必须符合此模式。当这是一个模式数组并且实例值为数组时，实例数组中的每个位置都必须符合此数组中相应位置的模式。这称为元组类型。使用元组类型时，附加项将根据对象额外属性的相同规则使用 additionalProperties 属性允许、禁止或约束。

5.4.  可选

这表示实例对象中的实例属性是可选的。默认情况下为 false。

5.5.  additionalProperties

这为对象类型定义中未明确定义的所有属性提供默认属性定义。该值必须是一个模式。如果提供 false，则不允许任何其他属性，并且不能扩展模式。默认值为一个空模式，允许其他属性使用任何值。

5.6.  要求

这表示如果此属性存在于包含的实例对象中，则 requires 属性给出的属性也必须存在于包含的实例对象中。此属性的值可以是字符串，表示所需的属性名称。或者该值可以是模式，在这种情况下，如果存在该属性，则包含的实例必须通过该模式验证。例如，如果定义了对象类型定义

{
  "state":
  {
    "optional":true
  },
  "town":
  {
    "requires":"state",
    "optional":true
  }
}

如果包含 town 属性，则实例必须包含 state 属性。如果未包含 town 属性，则 state 属性是可选的。

5.7.  最小值

当实例值的类型为数字时，这表示实例属性的最小值。

5.8.  最大值

当实例值的类型为数字时，这表示实例属性的最小值。

5.9.  minimumCanEqual

如果定义了最小值，则这表示实例属性值是否可以等于最小值。

5.10.  maximumCanEqual

如果定义了最大值，则这表示实例属性值是否可以等于最大值。

5.11.  minItems

当数组是实例值时，这表示数组中值的最小数量。

5.12.  maxItems

当数组是实例值时，这表示数组中值的最多数量。

5.13.  模式

当实例值为字符串时，这提供了一个正则表达式，实例字符串值应与之匹配以使其有效。正则表达式应遵循 ECMA 262/Perl 5 中的正则表达式规范

5.14.  maxLength

当实例值为字符串时，这表示字符串的最大长度。

5.15.  minLength

当实例值为字符串时，这表示字符串的最小长度。

5.16.  枚举

这提供了对实例属性有效的可能值的枚举。这应该是一个数组，数组中的每一项都表示实例值的可能值。如果包含 "enum"，则实例值必须是 enum 数组中的值之一，才能使模式有效。

5.17.  标题

这提供了实例属性的简短描述。该值必须是字符串。

5.18.  描述

这提供了实例属性目的的完整描述。该值必须是字符串。

5.19.  格式

此属性指示实例属性值中应预期的类型数据、内容类型或微格式。格式属性可以是以下列出的值之一，如果是这样，则应遵循对格式的语义描述。格式仅应用于对基本类型（字符串、整数、数字或布尔值）赋予含义。验证器不需要验证实例值是否符合格式。定义了以下格式

任何有效的 MIME 媒体类型都可以用作格式值，在这种情况下，实例属性值必须是字符串，表示 MIME 文件的内容。

date-time - 这应该是一个以 UTC 时间的 YYYY-MM-DDThh:mm:ssZ 的 ISO 8601 格式表示的日期。这是推荐的日期/时间戳形式。

date - 这应该是一个 YYYY-MM-DD 格式的日期。建议使用 "date-time" 格式而不是 "date"，除非您只需要传输日期部分。

time - 这应该是一个 hh:mm:ss 格式的时间。建议使用 "date-time" 格式而不是 "time"，除非您只需要传输时间部分。

utc-millisec - 这应该是指定时间与 1970 年 1 月 1 日午夜 UTC 之间的差异，以毫秒为单位。该值应该是一个数字（整数或浮点数）。

regex - 正则表达式。

color - 这是一种 CSS 颜色（如 "#FF0000" 或 "red"）。

style - 这是一种 CSS 样式定义（如 "color: red; background-color:#FFF"）。

phone - 这应该是一个电话号码（格式可能遵循 E.123）。

uri - 此值应该是一个 URI。

email - 这应该是一个电子邮件地址。

ip-address - 这应该是一个 IPv4 地址。

ipv6 - 这应该是一个 IPv6 地址。

street-address - 这应该是一个街道地址。

locality - 这应该是一个城市或城镇。

region - 这应该是一个地区（美国的一个州、加拿大的一个省份等）。

postal-code - 这应该是一个邮政编码（又称邮政编码）。

country - 这应该是一个国家的名称。

可以使用指向格式定义的 URL 来定义其他自定义格式。

5.20.  contentEncoding

如果实例属性值为字符串，则这表示该字符串应解释为二进制数据，并使用此模式属性命名的编码进行解码。RFC 2045，第 6.1 节列出了可能的值。

5.21.  默认

这表示实例属性的默认值。

5.22.  maxDecimal

这表示浮点数中最多的小数位数。默认情况下，没有最大值。

5.23.  不允许

此属性可以采用与 "type" 属性相同的值，但是如果实例匹配该类型，或者此值为数组并且实例匹配数组中的任何类型或模式，则此实例无效。

5.24.  扩展

此属性的值应该是另一个模式，它将提供一个基本模式，当前模式将继承自该模式。继承规则是这样的，任何根据当前模式有效的实例都必须根据引用模式有效。这也可以是一个数组，在这种情况下，实例必须对数组中的所有模式有效。

6.  超级模式

本节定义了 JSON 模式的超媒体定义。除了 JSON 模式已经提供的那些属性外，以下属性还被指定用于向用户代理通知基于 JSON 数据的资源之间的关系。与 JSON 模式属性一样，超级模式中的所有属性都是可选的。因此，一个空对象是一个有效的（非信息性的）模式，本质上描述了纯 JSON（对结构没有约束）。属性的添加为用户代理提供了附加信息。

6.1.  链接

links 属性的值应该是一个数组，数组中的每一项都是一个链接描述对象，它描述了实例的链接关系。

6.1.1.  链接描述对象

链接描述对象用于描述模式实例的链接关系。

6.1.1.1.  href

“href” 链接描述属性的值表示相关资源的目标 URI。实例属性的值应根据 [RFC3986] 解析为 URI 引用，可以是相对 URI。用于相对解析的基 URI 应该是用于检索实例对象的 URI（而不是模式）。此外，URI 可以通过实例对象的属性值进行参数化。

实例属性值应替换到 URI 中，其中找到围绕零个或多个字符的匹配花括号（'{'、'}'），创建扩展 URI。实例属性值替换通过使用花括号之间的文本来表示来自实例的属性名称以获取要替换的值来解析。例如，如果定义了 href 值

http://somesite.com/{id}

然后它将通过替换来自实例对象的 "id" 属性值的进行解析。如果 "id" 属性的值为 "45"，则扩展 URI 将为

http://somesite.com/45

如果在花括号之间找到匹配的花括号，并且花括号之间包含字符串 "-this"（不带引号），则应使用实际的实例值来替换花括号，而不是属性值。这应该只在实例是标量（字符串、布尔值或数字）的情况下使用，而不适用于对象或数组。

6.1.1.2.  rel

“rel” 属性的值表示与目标资源的关系名称。与目标的关系应解释为专门来自模式（或子模式）适用的实例对象，而不仅仅是包含该对象在其层次结构中的顶层资源。如果资源 JSON 表示包含一个属性被解释为链接的子对象，则该子对象与目标具有关系。来自顶层资源的目标关系必须通过描述顶层 JSON 表示的模式来指示。

关系定义不应依赖于媒体类型，鼓励用户利用现有的公认关系定义，包括现有的关系注册表中的关系定义（参见 &rfc4287）。但是，为了清楚起见，我们在 JSON 超级模式定义的关系上下文中定义了这些关系。

self - 如果关系值为 "self"，则在实例对象中遇到此属性时，该对象表示一个资源，并且实例对象被视为由指定 URI 标识的目标资源的完整表示。

full - 这表示链接的目标是实例对象的完整表示。包含此链接的对象可能不是完整表示。

describedby - 这表示链接的目标是实例对象的模式。这可以用来专门表示 JSON 对象层次结构中对象的模式，促进多态类型数据结构。

以下关系适用于模式（模式作为关系中的“from”资源）。

instances - 这表示代表模式实例集合的目标资源。

create - 这表示用于创建模式新实例的目标。此链接定义应该是具有非安全方法（如 POST）的提交链接。

例如，如果定义了一个模式

{
    "links": [
    	{
    		"rel": "self"
    		"href": "{id}"
    	},
    	{
    		"rel": "up"
    		"href": "{upId}"
    	},
    	{
    		"rel": "children"
    		"href": "?upId={id}"
    	}
    ]
}

并且如果检索到实例资源 JSON 表示的集合

GET /Resource/

[
    {
        "id": "thing",
        "upId": "parent"
    },
    {
        "id": "thing2",
        "upId": "parent"
    }
]

这将表明，对于集合中的第一项，它自己的（self）URI 将解析为 "/Resource/thing"，并且第一项的 "up" 关系应解析为位于 "/Resource/parent" 的资源。"children" 集合将位于 "/Resource/?upId=thing"。

6.1.1.3.  提交链接属性

以下属性也适用于链接定义对象，并提供类似于 HTML 表单的功能，为向服务器提交额外信息（通常是用户提供的信息）提供了一种手段。

6.1.1.3.1.  方法

这表示应使用哪种方法访问目标资源。在 HTTP 环境中，这将是 "GET" 或 "POST"（其他 HTTP 方法，如 "PUT" 和 "DELETE" 具有由访问的资源明确暗示的语义，不需要在这里定义）。默认值为 "GET"。

6.1.1.3.2.  enctype

如果存在，此属性表示服务器支持用于查询或发布到目标资源的实例集合的查询媒体类型格式。查询可以附加到目标 URI 以使用基于属性的约束来查询集合，这些约束应从服务器返回或用于将数据发布到资源（取决于方法）。例如，使用以下模式

{
 "links":[
    {
      "enctype": "application/x-www-form-urlencoded",
      "method": "GET",
      "href": "/Product/",
      "properties":{
         "name":{"description":"name of the product"}
      }
    }
  ]
}

这表示客户端可以查询服务器以获取具有特定名称的实例

/Product/?name=Slinky

如果未指定 enctype 或方法，则仅定义 href 属性指定的单个 URI。如果方法是 POST，则 application/json 是默认媒体类型。

6.1.1.3.3.  属性

这是从基本 JSON 架构定义继承而来的，并且可以遵循相同的结构，但其含义应用于定义操作的可接受属性名称和值（无论是 GET 查询还是 POST 正文）。如果省略属性，并且此表单是架构的子级，则应使用父架构中的属性作为表单操作的基础。

6.2.  fragmentResolution

此属性表示用于解析实例表示中 URI 中的片段标识符的片段解析协议。这适用于实例对象 URI 和实例对象 URI 的所有子级。默认片段解析协议为“点分隔”，如下定义。可以使用其他片段解析协议，但未在此文档中定义。

片段标识符基于 RFC 2396 第 5 节，并定义了解决对文档内实体引用的机制。

6.2.1.  点分隔片段解析

使用点分隔片段解析协议，片段标识符被解释为一系列以“.” 字符（\x2E）分隔的属性引用标记。每个属性引用标记是一系列除“.” 字符之外的任何合法 URI 组件字符。每个属性引用标记应从片段标识符的开头开始解释，作为目标 JSON 结构中的路径引用。片段的最终目标值可以通过从由片段前 URI 标识的资源的表示开始的 JSON 结构的根来确定。如果目标是 JSON 对象，则新目标是名称由片段中的下一个属性引用标记标识的属性的值。如果目标是 JSON 数组，则目标通过在数组中查找索引由下一个属性引用标记定义的项目来确定（该标记必须是数字）。对于每个属性引用标记，目标会依次更新，直到遍历完整个片段。

属性名称应使用 URI 编码。特别是，属性名称中的任何“.” 必须编码以避免被解释为属性分隔符。

例如，对于以下 JSON 表示

{
   "foo":{
      "anArray":[
        {"prop":44}
      ],
      "another prop":{
          "baz":"A string"
      }
   }
}

将解析以下片段标识符

fragment identifier    resolution
-------------------    ----------
#                      self, the root of the resource itself
#foo                   the object referred to by the foo property
#foo.another prop      the object referred to by the "another prop"
                       property of the object referred to by the
                       "foo" property
#foo.another prop.baz  the string referred to by the value of "baz"
                       property of the "another prop" property of
                       the object referred to by the "foo" property
#foo.anArray.0         the first object in the "anArray" array

6.3.  root

此属性表示实例属性值的 SHOULD 被视为表示的根或主体，以用于用户代理交互和片段解析（实例对象的 所有其他属性可以被视为数据的元数据描述）。

6.4.  readonly

这表示不应更改实例属性。用户代理修改此属性值的尝试预计会被服务器拒绝。

6.5.  pathStart

此属性值是一个 URI 引用，表示架构实例的所有 URI 应该以该 URI 开头。当为一个实例引用了多个架构时，用户代理可以通过确定实例的 URI 是否以 pathStart 引用的 URI 开头来确定此架构是否适用于特定实例。pathStart 必须根据 [RFC3986] 第 5 节进行解析。如果实例的 URI 不以 pathStart 指示的 URI 开头，或者其他架构指定了一个更长且也匹配实例的起始 URI，则此架构不应应用于该实例。任何没有 pathStart 属性的架构都应被视为适用于所有引用它的实例。

6.6.  mediaType

这表示此架构定义的实例表示的媒体类型。

6.7.  alternate

这是一个 JSON 架构定义数组，定义了实例资源的任何其他基于 JSON 的表示的备用架构。

7.  安全考虑因素

此规范是 JSON 格式的子类型，因此安全考虑因素通常与 RFC 4627 相同。但是，另一个问题是，当“self”链接关系用于表示对象的完整表示时，如果目标 URI 不等效于或目标 URI 的子路径，用户代理 SHOULD NOT 将表示视为目标 URI 表示的资源的权威表示 用于请求包含带有“self”链接的目标 URI 的资源表示的 URI。例如，如果定义了超架构

{
  "links":[
  	{
  		"rel":"self",
  		"href":"{id}"
  	}
  ]
}

并且从 somesite.com 请求了资源

GET /foo/

并响应

Content-Type: application/json; describedby=/schema-for-this-data
[
  {"id":"bar", "name":"This representation can be safely treated \
        as authoritative "},
  {"id":"/baz", "name":"This representation should not be treated as \
        authoritative the user agent should make request the resource\
        from "/baz" to ensure it has the authoritative representation"},
  {"id":"http://othersite.com/something", "name":"This representation\
        should also not be treated as authoritative and the target\
        resource representation should be retrieved for the\
        authoritative representation"}
]

8.  IANA 考虑因素

建议用于 JSON 架构的 MIME 媒体类型为 application/schema+json

类型名称：application

子类型名称：schema+json

必需参数：describedby

describedby 参数的值应该是一个 URI（相对或绝对），它引用用于定义此结构（元架构）的结构的架构。通常，该值将是 https://json-schema.fullstack.org.cn/hyper-schema，但允许使用扩展超架构的元架构的其他架构。

可选参数：pretty

pretty 参数的值可以是 true 或 false，以指示是否包含额外的空格以使 JSON 表示更易于阅读。

8.1.  链接关系注册表

此注册表由 IANA 根据 RFC 4287 维护，此规范添加了三个值：“full”、“create”、“instances”。新的分配需要 IESG 批准，如 [RFC5226] 中所述。请求应通过电子邮件发送给 IANA，然后 IANA 将请求转发给 IESG，以请求批准。

9.  参考资料

9.1.  规范性引用

9.2.  说明性引用

附录 A.  更改日志

-01

• 修复类别并从模板更新

-00

• 初始草稿

附录 B.  未解决的问题

我们应该优先考虑 MIME 标头而不是链接标头（或者只使用其中一个）吗？

我们应该使用“profile”作为媒体类型参数吗？

“root”是否应该作为 MIME 参数而不是架构属性？

“format”是否应该重命名为“mediaType”或“contentType”，以反映允许使用的 MIME 媒体类型。

我仍然不喜欢日期的处理方式。

作者地址