用於描述 JSON 文件結構與意義的 JSON 媒體類型
draft-zyp-json-schema-01

摘要

JSON (JavaScript 物件表示法) Schema 定義了媒體類型 application/schema+json，這是一種基於 JSON 的格式，用於定義 JSON 資料的結構。JSON Schema 為給定應用程式所需的 JSON 資料以及如何與之互動提供了一個契約。JSON Schema 的目的是定義 JSON 資料的驗證、文件、超連結導覽和互動控制。

本備忘錄的狀態

本網際網路草案的提交完全符合 BCP 78 和 BCP 79 的規定。

網際網路草案是網際網路工程任務組 (IETF) 及其領域和工作組的工作文件。請注意，其他組也可以將工作文件作為網際網路草案發布。

網際網路草案是有效期最長為六個月的草案文件，隨時可能被其他文件更新、取代或廢止。將網際網路草案用作參考資料或將其引用為「正在進行的工作」以外的用途是不恰當的。

可以從 http://www.ietf.org/ietf/1id-abstracts.txt 存取目前網際網路草案的清單。

可以從 http://www.ietf.org/shadow.html 存取網際網路草案陰影目錄的清單。

本網際網路草案將於 2010 年 6 月 8 日到期。

版權聲明

版權所有 (c) 2009 IETF Trust 和被認定為文件作者的人員。保留所有權利。

本文件受 BCP 78 和 IETF Trust 的 IETF 文件法律條款 (http://trustee.ietf.org/license-info) 約束，該條款於本文件發布之日生效。請仔細閱讀這些文件，因為它們描述了您對本文件的權利和限制。從本文件中提取的程式碼元件必須包含「信託法律條款」第 4.e 節中所述的簡化 BSD 許可證文字，並按 BSD 許可證中所述提供，不提供任何保證。

目錄

1.  簡介
2.  慣例
3.  概述
    3.1.  術語
    3.2.  設計考量
4.  Schema/實例關聯
    4.1.  自我描述的 Schema
5.  核心 Schema 定義
    5.1.  type
    5.2.  properties
    5.3.  items
    5.4.  optional
    5.5.  additionalProperties
    5.6.  requires
    5.7.  minimum
    5.8.  maximum
    5.9.  minimumCanEqual
    5.10.  maximumCanEqual
    5.11.  minItems
    5.12.  maxItems
    5.13.  pattern
    5.14.  maxLength
    5.15.  minLength
    5.16.  enum
    5.17.  title
    5.18.  description
    5.19.  format
    5.20.  contentEncoding
    5.21.  default
    5.22.  maxDecimal
    5.23.  disallow
    5.24.  extends
6.  超級 Schema
    6.1.  links
        6.1.1.  連結描述物件
    6.2.  片段解析
        6.2.1.  點號分隔的片段解析
    6.3.  root
    6.4.  readonly
    6.5.  pathStart
    6.6.  mediaType
    6.7.  alternate
7.  安全性考量
8.  IANA 考量
    8.1.  連結關係登錄
9.  參考文獻
    9.1.  規範性參考文獻
    9.2.  資訊性參考文獻
附錄 A.  變更記錄
附錄 B.  未決議題

1.  簡介

JSON (JavaScript 物件表示法) Schema 是一種 JSON 媒體類型，用於定義 JSON 資料的結構。JSON Schema 為給定應用程式所需的 JSON 資料以及如何與之互動提供了一個契約。JSON Schema 的目的是定義 JSON 資料的驗證、文件、超連結導覽和互動控制。

2.  慣例

本文件中，「必須 (MUST)」、「不得 (MUST NOT)」、「必要 (REQUIRED)」、「應 (SHALL)」、「不應 (SHALL NOT)」、「應該 (SHOULD)」、「不應該 (SHOULD NOT)」、「建議 (RECOMMENDED)」、「可以 (MAY)」和「可選 (OPTIONAL)」等關鍵字應按照 RFC 2119 中所述進行解釋。

3.  概述

JSON Schema 定義了媒體類型 application/schema+json，用於描述其他 JSON 文件的結構。JSON Schema 是基於 JSON 的，並且包括用於根據允許值、描述和解釋與其他資源關係來描述 JSON 文件結構的機制。

JSON Schema 格式組織成幾個單獨的定義。第一個定義是核心 schema 規範。此定義主要關注描述 JSON 結構並指定結構中的有效元素。第二個定義是超級 Schema 規範，旨在定義結構中可以解釋為超連結的元素。超級 Schema 建構於 JSON Schema 之上，以描述其他 JSON 文件的超連結結構。這使得使用者代理能夠根據其 schema 成功導覽 JSON 文件。

總體而言，JSON Schema 充當一個元文件，可用於定義屬性值的必要類型和約束，以及定義屬性值的含義，以描述資源並確定表示中的超連結。

描述產品的範例 JSON Schema 可能如下所示

{
  "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}"
    }
  ]
}

此 schema 定義了實例 JSON 文件的屬性及其必要屬性 (id、name 和 price) 以及可選屬性 (tags)。這也定義了實例 JSON 文件的連結關係。

3.1.  術語

對於本規範，schema 將用於表示 JSON Schema 定義，而實例是指 schema 將要描述和驗證的 JSON 物件或陣列

3.2.  設計考量

JSON Schema 媒體類型不嘗試規定包含資料的 JSON 表示形式的結構，而是提供一種單獨的格式，用於彈性地傳達應如何解釋和驗證 JSON 表示形式，以便使用者代理可以正確理解可接受的結構，並使用 JSON 文件外推超連結資訊。本規範未定義協定。底層協定 (例如 HTTP) 應充分定義用戶端伺服器介面的語義、檢索連結到 JSON 表示形式的資源表示形式以及修改這些資源。此格式的目標是充分描述 JSON 結構，以便可以利用現有 JSON 表示形式中可用的現有資訊，這些資訊來自利用 REST 架構並使用現有協定的各種服務。

4.  Schema/實例關聯

JSON Schema 實例透過「describedby」關係與其 schema 相關聯，其中 schema 定義為關係的目標。實例表示形式可能是 application/json 媒體類型或任何其他子類型。因此，規定實例表示形式應如何指定與 schema 的關係超出了本文檔的規範範圍 (因為本文檔專門定義了 JSON Schema 媒體類型，而非其他)，但建議實例指定其 schema，以便使用者代理可以解釋實例表示形式，並且訊息可以保留自我描述的特性，避免需要關於實例資料的頻外資訊。建議使用兩種方法來宣告與描述 JSON 實例 (或實例集合) 結構含義的 schema 的關係。應使用名為「describedby」的 MIME 類型參數或具有「describedby」關係的連結標頭

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

或者，如果內容是透過提供標頭的協定 (例如 HTTP) 傳輸的，則可以使用連結標頭

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

實例可以指定多個 schema，以指示所有適用於該資料的 schema。實例資料可能有多個 schema 定義 (實例資料對於這些 schema 應有效)。或者，如果文件是實例的集合，則該集合可能包含來自不同 schema 的實例。當集合包含異質實例時，可以在 schema 中指定 pathStart 屬性，以消除歧義，確定應將哪個 schema 應用於集合中的每個項目。

4.1.  自我描述的 Schema

JSON Schema 本身是 schema schema 的實例。核心 JSON Schema 的自我描述 JSON Schema 可以在 https://json-schema.dev.org.tw/schema 找到，而超級 schema 自我描述可以在 https://json-schema.dev.org.tw/hyper-schema 找到。在具有媒體類型定義的協定中使用的所有 schema 都應包含一個 MIME 參數，該參數引用自我描述的超級 schema 或擴充此超級 schema 的另一個 schema

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

5.  核心 Schema 定義

JSON Schema 是一個 JSON 物件，用於定義實例的各種屬性，並定義其實例的用法和有效值。JSON Schema 是一個具有 schema 屬性屬性的 JSON 物件。以下是 JSON Schema 的語法

範例 JSON Schema 定義可能如下所示

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

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

JSON Schema 物件可能具有以下任何屬性 (稱為 schema 屬性) (所有屬性都是可選的)

5.1.  type

聯合類型定義 - 具有兩個或更多項目的陣列，表示類型定義的聯合。陣列中的每個項目可以是簡單類型定義或 schema。如果實例值與陣列中一個類型定義的類型相同，或者如果它通過陣列中的一個 schema 有效，則實例值是有效的。例如，若要表示字串或數字有效：{"type":["string","number"]}

簡單類型定義 - 表示基本或簡單類型的字串。以下是可接受的字串

string - 值必須是字串。

number - 值必須是數字，允許使用浮點數。

integer - 值必須是整數，不允許使用浮點數。這是數字類型的子集。

boolean - 值必須是布林值。

object - 值必須是物件。

array - 值必須是陣列。

null - 值必須為 null。請注意，這主要是為了能夠使用聯合類型來定義可空性。

any - 值可以是任何類型，包括 null。如果屬性未定義或不在清單中，則可以接受任何類型的值。其他類型值可用於自訂用途，但規格實作的最小驗證器可以允許未知類型值的任何實例值。

5.2.  properties

這應該是物件類型定義，這是一個具有與實例物件屬性對應的屬性定義的物件。當實例值是物件時，實例物件的屬性值必須符合此物件中的屬性定義。在此物件中，每個屬性定義的值都應該是一個 schema，並且屬性的名稱應該是它定義的實例屬性的名稱。

5.3.  items

這應該是一個 schema 或一個 schema 的陣列。當這是一個物件/schema 且實例值是陣列時，陣列中的所有項目都必須符合此 schema。當這是一個 schema 的陣列且實例值是一個陣列時，實例陣列中的每個位置都必須符合此陣列中相應位置的 schema。這稱為元組類型。當使用元組類型時，允許使用其他項目、不允許使用或受到 additionalProperties 屬性的約束，其規則與物件的額外屬性相同。

5.4.  optional

這表示實例物件中的實例屬性是可選的。預設值為 false。

5.5.  additionalProperties

這為物件類型定義中未明確定義的所有屬性提供預設屬性定義。該值必須是一個 schema。如果提供 false，則不允許使用其他屬性，並且 schema 不能擴展。預設值為空的 schema，這允許額外屬性使用任何值。

5.6.  requires

這表示如果包含的實例物件中存在此屬性，則必須在包含的實例物件中也存在由 requires 屬性給定的屬性。此屬性的值可以是字串，表示所需的屬性名稱。或者，該值可以是 schema，在這種情況下，如果屬性存在，則包含的實例必須符合 schema 的有效性。例如，如果定義了物件類型定義

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

如果包含 town 屬性，則實例必須包含 state 屬性。如果未包含 town 屬性，則 state 屬性是可選的。

5.7.  minimum

這表示當實例值的類型為數字時，實例屬性的最小值。

5.8.  maximum

這表示當實例值的類型為數字時，實例屬性的最小值。

5.9.  minimumCanEqual

如果定義了最小值，這表示實例屬性值是否可以等於最小值。

5.10.  maximumCanEqual

如果定義了最大值，這表示實例屬性值是否可以等於最大值。

5.11.  minItems

這表示當陣列為實例值時，陣列中的最小值數量。

5.12.  maxItems

這表示當陣列為實例值時，陣列中的最大值數量。

5.13.  pattern

當實例值為字串時，這提供一個正規表示式，實例字串值應符合此正規表示式，才能有效。正規表示式應遵循 ECMA 262/Perl 5 的正規表示式規範

5.14.  maxLength

當實例值為字串時，這表示字串的最大長度。

5.15.  minLength

當實例值為字串時，這表示字串的最小長度。

5.16.  enum

這提供了一組實例屬性有效值的可能列舉。這應該是一個陣列，且陣列中的每個項目代表實例值的可能值。如果包含 "enum"，則實例值必須是 enum 陣列中的值之一，schema 才能有效。

5.17.  title

這提供實例屬性的簡短描述。該值必須是字串。

5.18.  description

這提供實例屬性用途的完整描述。該值必須是字串。

5.19.  format

此屬性表示實例屬性值中預期的資料類型、內容類型或微格式。格式屬性可以是下面列出的值之一，如果是，則應遵循描述該格式的語意。格式應僅用於賦予基本類型（字串、整數、數字或布林值）意義。驗證器不需要驗證實例值是否符合格式。定義了以下格式

任何有效的 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 - 這應該是一個 IP 版本 4 位址。

ipv6 - 這應該是一個 IP 版本 6 位址。

street-address - 這應該是一個街道地址。

locality - 這應該是一個城市或城鎮。

region - 這應該是一個地區（美國的一個州、加拿大的省等）

postal-code - 這應該是一個郵遞區號（又稱 ZIP 碼）。

country - 這應該是一個國家/地區的名稱。

可以使用指向格式定義的 URL 定義其他自訂格式。

5.20.  contentEncoding

如果實例屬性值是一個字串，這表示該字串應被解釋為二進位資料，並使用此 schema 屬性命名的編碼進行解碼。RFC 2045, Sec 6.1 列出了可能的值。

5.21.  default

這表示實例屬性的預設值。

5.22.  maxDecimal

這表示浮點數中小數點後的最大位數。預設情況下沒有最大值。

5.23.  disallow

此屬性可以採用與 "type" 屬性相同的值，但是如果實例符合類型，或者此值是一個陣列，且實例符合陣列中的任何類型或 schema，則此實例無效。

5.24.  extends

此屬性的值應該是另一個 schema，它將提供當前 schema 將繼承的基礎 schema。繼承規則是，根據當前 schema 有效的任何實例都必須根據引用的 schema 有效。這也可以是一個陣列，在這種情況下，實例對於陣列中的所有 schema 必須有效。

6.  Hyper Schema

本節定義 JSON schema 的超媒體定義。除了 JSON schema 已經提供的屬性外，還指定了以下屬性，其特定目的是告知使用者代理基於 JSON 資料的資源之間的關係。就像 JSON schema 屬性一樣，hyper-schema 中的所有屬性都是可選的。因此，空物件是一個有效的（非資訊性的）schema，並且基本上描述了純 JSON（對結構沒有約束）。新增屬性可為使用者代理提供累加資訊。

6.1.  links

links 屬性的值應為陣列，其中陣列中的每個項目都是連結描述物件，用於描述實例的連結關係。

6.1.1.  連結描述物件

連結描述物件用於描述 schema 實例的連結關係。

6.1.1.1.  href

"href" 連結描述屬性的值表示相關資源的目標 URI。實例屬性的值應按照 [RFC3986] 解析為 URI 參考，並且可以是相對 URI。用於相對解析的基本 URI 應該是用於檢索實例物件的 URI (而不是 schema)。此外，URI 可以透過實例物件的屬性值進行參數化。

應將實例屬性值替換到在找到零個或多個字元包圍的匹配大括號 ('{', '}') 的 URI 中，以建立擴展的 URI。實例屬性值替換是透過使用大括號之間的文字來表示實例中的屬性名稱，以取得要替換的值來解析的。例如，如果定義了 href 值

http://somesite.com/{id}

那麼它會透過替換實例物件中的 "id" 屬性值來解析。如果 "id" 屬性的值為 "45"，則擴展的 URI 將為

http://somesite.com/45

如果在匹配的大括號之間找到字串 "-this"（無引號），則應使用實際的實例值替換大括號，而不是屬性值。這應僅在實例為純量（字串、布林值或數字）的情況下使用，而不適用於物件或陣列。

6.1.1.2.  rel

"rel" 屬性的值表示與目標資源的關係名稱。與目標的關係應解釋為特別來自於 schema (或子 schema) 套用到的實例物件，而不僅僅是包含該物件的頂層資源。如果資源 JSON 表示包含一個具有屬性被解釋為連結的子物件，則該子物件與目標保持關係。必須使用描述頂層 JSON 表示的 schema 來指示與頂層資源的目標關係。

關係定義不應依賴媒體類型，並且鼓勵使用者利用現有的接受關係定義，包括現有關係註冊中的定義（請參閱 &rfc4287）。但是，我們在這裡定義這些關係是為了在 JSON 超 schema 定義關係的上下文中明確規範地解釋。

self - 如果關係值為 "self"，當在實例物件中遇到此屬性時，該物件表示一個資源，並且該實例物件被視為指定 URI 所識別的目標資源的完整表示。

full - 這表示連結的目標是實例物件的完整表示。包含此連結的物件可能不是完整表示。

describedby - 這表示連結的目標是實例物件的 schema。這可以用於專門表示 JSON 物件層次結構中物件的 schema，從而促進多型類型資料結構。

以下關係適用於 schema（schema 作為關係中的「來源」資源）。

instances - 這表示目標資源，該資源表示 schema 的實例集合。

create - 這表示用於建立 schema 新實例的目標。此連結定義應該是一個具有非安全方法（如 POST）的提交連結。

例如，如果定義了一個 schema

{
    "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.  method

這表示應使用哪種方法來存取目標資源。在 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 或 method，則僅定義由 href 屬性指定的單個 URI。如果 method 是 POST，則 application/json 是預設媒體類型。

6.1.1.3.3. 屬性

這繼承自基本的 JSON 綱要定義，並且可以遵循相同的結構，但其含義應被用於定義動作的可接受屬性名稱和值（無論是 GET 查詢還是 POST 內文）。如果省略屬性，且此表單是綱要的子項，則應使用父綱要中的屬性作為表單動作的基礎。

6.2. 片段解析

此屬性指示用於解析實例表示形式中 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. 根

此屬性表示，為了使用者代理互動和片段解析的目的，實例屬性值應被視為表示形式的根或內文（實例物件的所有其他屬性可以被視為資料的中繼資料描述）。

6.4. 唯讀

這表示實例屬性不應被更改。使用者代理修改此屬性值的嘗試預計將被伺服器拒絕。

6.5. 路徑起點

此屬性值是 URI 參照，表示綱要實例的所有 URI 應以之為開頭的 URI。當多個綱要已針對實例被參照時，使用者代理可以透過確定實例的 URI 是否以 pathStart 所參照的 URI 開頭來確定此綱要是否適用於特定實例。pathStart 必須按照 [RFC3986] 第 5 節進行解析。如果實例的 URI 並非以 pathStart 所指示的 URI 開頭，或者另一個綱要指定了更長且也與實例匹配的起始 URI，則不應將此綱要應用於實例。任何沒有 pathStart 屬性的綱要都應被視為適用於其被參照的所有實例。

6.6. 媒體類型

這表示此綱要正在定義的實例表示形式的媒體類型。

6.7. 替代

這是一個 JSON 綱要定義陣列，定義了實例資源的任何其他基於 JSON 的替代表示形式的綱要。

7. 安全考量

此規範是 JSON 格式的子類型，因此安全考量通常與 RFC 4627 相同。然而，另一個額外問題是，當使用「self」的連結關係來表示物件的完整表示形式時，如果目標 URI 不等於或不是用於請求包含具有「self」連結的目標 URI 的資源表示形式的 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.dev.org.tw/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 媒體類型。

我仍然不喜歡日期的處理方式。

作者地址