| 網際網路工程任務組 | 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.dev.org.tw/>。
如需提供意見回饋，請使用此問題追蹤器、首頁上列出的通訊方法，或發送電子郵件給文件編輯者。
本網路草案的提交完全符合 BCP 78 和 BCP 79 的規定。
網路草案是網際網路工程任務組 (IETF) 的工作文件。請注意，其他群體也可能將工作文件以網路草案的形式發佈。目前的網路草案清單請見 http://datatracker.ietf.org/drafts/current/。
網路草案是有效期最長為六個月的草案文件，並可能隨時被其他文件更新、取代或廢棄。將網路草案作為參考資料或引用它們（除非作為「工作進行中」）是不恰當的。
本網路草案將於 2018 年 9 月 20 日到期。
版權 (c) 2018 IETF Trust 和被識別為文件作者的人士所有。保留所有權利。
本文件受 BCP 78 和 IETF Trust 的 IETF 文件法律條款 (http://trustee.ietf.org/license-info) 的約束，該條款在本文件發佈之日生效。請仔細查閱這些文件，因為它們描述了您對本文件的權利和限制。從本文件中提取的程式碼元件必須包含「簡化 BSD 授權」文字，如 Trust 法律條款第 4.e 節所述，並按「簡化 BSD 授權」所述提供，不提供擔保。
JSON Schema 是一種用於定義 JSON 資料結構的 JSON 媒體類型。JSON Schema 的目的在於定義 JSON 資料的驗證、文件、超連結導覽和互動控制。
本規範定義了 JSON Schema 的核心術語和機制，包括透過參考指向另一個 JSON Schema、取消參照 JSON Schema 參考以及指定正在使用的詞彙表。
其他規範定義了執行關於驗證、連結、註解、導覽和互動聲明的詞彙表。
本文件中使用的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」應按照 RFC 2119 [RFC2119] 中的說明進行解釋。
本文件中使用的術語「JSON」、「JSON 文字」、「JSON 值」、「成員」、「元素」、「物件」、「陣列」、「數字」、「字串」、「布林值」、「true」、「false」和「null」應按照 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 就可以使用資訊來註解實例。
詳細的註解行為以及一小組基本註解關鍵字在驗證規範 [json-schema-validation]中定義。
JSON 超綱要描述 JSON 文件的超文字結構。這包括從實例到其他資源的連結關係、將實例解釋為多媒體資料，以及使用 API 所需的提交資料。
超綱要行為和關鍵字在另一份文件 [json-hyper-schema]中指定。
JSON 文件是由 application/json 媒體類型描述的資訊資源（一系列八位元組）。
在 JSON Schema 中，由於它定義的資料模型，術語「JSON 文件」、「JSON 文字」和「JSON 值」可以互換使用。
JSON Schema 僅針對 JSON 文件定義。但是，任何可以根據 JSON Schema 資料模型解析或處理的文件或記憶體結構，都可以根據 JSON Schema 進行解釋，包括諸如 CBOR [RFC7049] 之類的媒體類型。
應用綱要的 JSON 文件稱為「實例」。
JSON Schema 根據資料模型解釋文件。根據此資料模型解釋的 JSON 值稱為「實例」。
實例具有六種基本類型之一，並且具有取決於類型的可能值範圍
因此，空白和格式問題，包括資料模型中相等的數字的不同詞法表示，都超出了 JSON Schema 的範圍。希望使用詞法表示差異的 JSON Schema 詞彙表 [vocabulary] 應該定義關鍵字，以精確解釋資料模型中的格式化字串，而不是依賴於可用的原始 JSON 表示 Unicode 字元。
由於物件不能具有兩個具有相同鍵的屬性，因此嘗試在單一物件中定義兩個具有相同鍵（「字串」產生式）的屬性（「成員」產生式）的 JSON 文件的行為是未定義的。
請注意，JSON Schema 詞彙表可以自由定義它們自己的擴展類型系統。這不應與此處定義的核心資料模型類型混淆。例如，「integer」對於詞彙表而言，是一個合理的類型，可以定義為關鍵字的值，但資料模型不會區分整數和其他數字。
JSON Schema 設計為可與「application/json」文件以及使用「+json」結構化語法字尾的媒體類型完全協同工作。
每個媒體類型都定義了一些對於使用綱要有用的功能，即媒體類型參數和 URI 片段識別符的語法和語義。這些功能在內容協商和計算實例中特定位置的 URI 時非常有用。
本規範定義了「application/schema-instance+json」媒體類型，以便讓實例作者能夠充分利用參數和片段識別符來實現這些目的。
如果兩個 JSON 實例屬於相同類型，並且根據資料模型具有相同的值，則稱它們相等。具體而言，這表示：
此定義暗示陣列必須具有相同的長度，物件必須具有相同數量的成員，物件中的屬性是無序的，沒有辦法定義具有相同鍵值的多個屬性，而且僅僅是格式差異（縮排、逗號位置、尾隨零）是無關緊要的。
JSON Schema 文件，或簡稱 schema，是一個用來描述實例的 JSON 文件。schema 本身被解讀為一個實例，但是應該始終被賦予媒體類型 "application/schema+json"，而不是 "application/schema-instance+json"。"application/schema+json" 媒體類型被定義為提供比 "application/schema-instance+json" 提供的媒體類型參數和片段識別符語法和語義的超集。
JSON Schema 必須是一個物件或一個布林值。
應用於實例的物件屬性稱為關鍵字，或 schema 關鍵字。廣義來說，關鍵字分為以下一個或兩個類別：
關鍵字可能屬於一個或兩個類別。擴充關鍵字，即在本文件及其相關文件中定義的關鍵字之外，也可以自由定義其他行為。
布林值 schema 值 "true" 和 "false" 是微不足道的斷言，無論實例值如何，都始終返回自身。例如，在驗證詞彙表中，布林值 schema 等效於以下行為：
JSON Schema 可能包含不是 schema 關鍵字的屬性。未知的關鍵字應該被忽略。
空的 schema 是一個沒有屬性，或僅有未知屬性的 JSON Schema。
JSON Schema 詞彙表是一組為特定目的定義的關鍵字。詞彙表將其關鍵字的含義指定為斷言、註解，和/或任何詞彙表定義的關鍵字類別。本文件的兩個相關標準各自定義了一個詞彙表：一個用於實例驗證，另一個用於超媒體註解。詞彙表是 JSON Schema 媒體類型中擴充性的主要機制。
詞彙表可以由任何實體定義。如果詞彙表旨在廣泛使用，並可能與其他詞彙表組合，則詞彙表作者應注意避免關鍵字名稱衝突。JSON Schema 不提供任何正式的命名空間系統，但也不約束關鍵字名稱，允許任何數量的命名空間方法。
詞彙表可以彼此建立，例如通過定義其關鍵字在另一個詞彙表的關鍵字行為方面的行為，或通過使用另一個詞彙表的關鍵字，並使用一組受限制或擴充的可接受值。並非所有此類詞彙表重用都會產生一個與其建立的詞彙表兼容的新詞彙表。詞彙表作者應明確記錄預期兼容性的級別（如果有的話）。
一個描述 schema 本身的 schema 稱為 meta-schema。Meta-schema 用於驗證 JSON Schema，並指定其正在使用的詞彙表。[CREF1]目前，每個 schema 只能指定一個 meta-schema，這意味著為了使用多個詞彙表，必須編寫一個包含所有詞彙表的 meta-schema。超 schema meta-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 媒體類型指定的片段識別符的語法和語義，應該如同為 "application/json" 指定的那樣。（在本文件發布時，尚未定義 "application/json" 的片段識別符語法。）
此外，"application/schema+json" 媒體類型支援兩種片段識別符結構：純名稱和 JSON 指標。"application/schema-instance+json" 媒體類型支援一種片段識別符結構：JSON 指標。
JSON 指標作為 URI 片段識別符的使用，在 RFC 6901 [RFC6901] 中有描述。對於支援兩種片段識別符語法的 "application/schema+json"，符合 JSON 指標語法的片段識別符，包含空字串，都必須被解讀為 JSON 指標片段識別符。
根據 W3C 的片段識別符最佳實踐 [W3C.WD-fragid-best-practices-20121025]，"application/schema+json" 中的純名稱片段識別符保留用於引用本地命名的 schema。所有與 JSON 指標語法不符的片段識別符，都必須被解讀為純名稱片段識別符。
在 "application/schema+json" 文件中定義和引用純名稱片段識別符，在 "$id" 關鍵字 [id-keyword] 節中指定。
實例可以是 JSON [RFC7159] 定義的任何有效 JSON 值。JSON Schema 不對類型施加任何限制：JSON Schema 可以描述任何 JSON 值，包含 null。
JSON Schema 與程式語言無關，並支援資料模型中描述的全部值範圍。但是請注意，某些語言和 JSON 解析器可能無法在記憶體中表示 JSON 可以描述的全部值範圍。
某些程式語言和解析器對於浮點數和整數使用不同的內部表示法。
為了保持一致性，整數 JSON 數字不應該以小數部分編碼。
實作可以為 JSON Schema 定義額外的關鍵字。除非有明確的協議，否則 schema 作者不應期望對等實作支援這些額外的關鍵字。實作應該忽略它們不支持的關鍵字。
鼓勵 JSON Schema 擴充的作者編寫他們自己的 meta-schema，使用 "allOf" 擴充現有的 meta-schema。這個擴充的 meta-schema 應該使用 "$schema" 關鍵字引用，以允許工具遵循正確的行為。
請注意，meta-schema 的遞迴性質要求在擴充的 meta-schema 中重新定義遞迴關鍵字，正如在 JSON Hyper-Schema meta-schema 中看到的那樣。
"$schema" 關鍵字既用作 JSON Schema 版本識別符，又用作資源位置，該資源本身是一個 JSON Schema，描述了為此特定版本編寫的任何 schema。
此關鍵字的值必須是一個 URI [RFC3986]（包含一個協定），並且此 URI 必須正規化。目前的 schema 必須根據此 URI 識別的 meta-schema 有效。
如果此 URI 識別可檢索的資源，則該資源的媒體類型應該是 "application/schema+json"。
"$schema" 關鍵字應該在根 schema 中使用。它不得出現在子 schema 中。
此屬性的值在其他文件和其他方中定義。JSON Schema 實作應該實作對 JSON Schema 詞彙表目前和先前發布的草案的支援，視為合理。
為了區分廣大生態系統中的 schema，schema 由 URI [RFC3986] 識別，並且可以透過指定其 URI 嵌入對其他 schema 的引用。
RFC3986 第 5.1 節 [RFC3986] 定義了如何確定文件的預設基礎 URI。
通知性地，schema 的初始基礎 URI 是找到它的 URI，如果沒有已知的 URI，則是一個合適的替代 URI。
「$id」關鍵字定義了 schema 的 URI，以及 schema 中其他 URI 參考所解析的基礎 URI。子 schema 的「$id」會根據其父 schema 的基礎 URI 來解析。如果沒有父 schema 使用「$id」設定明確的基礎 URI，則基礎 URI 會是整個文件的 URI，如同 RFC 3986 第 5 節 [RFC3986] 所述。
如果存在此關鍵字，則其值必須是字串，並且必須代表一個有效的 URI 參考 [RFC3986]。此值應該正規化，並且不應該是空的片段 <#> 或空字串 <>。
JSON Schema 文件的根 schema 應該包含一個「$id」關鍵字，其值為一個 絕對 URI [RFC3986]（包含 scheme，但不包含片段），或此絕對 URI 但帶有一個空的片段。
當「$id」設定了基礎 URI 時，包含該「$id」的物件及其所有子 schema 都可以使用從該位置開始的 JSON 指標片段來識別。即使是進一步變更基礎 URI 的子 schema 也是如此。因此，單一子 schema 可以透過多個 URI 存取，每個 URI 由子 schema 或父 schema 中宣告的基礎 URI，以及識別從宣告基礎 URI 的 schema 物件到被識別的子 schema 的路徑的 JSON 指標片段組成。此範例展示在 8.2.4 節 中。
使用 JSON 指標片段需要了解 schema 的結構。當編寫旨在提供可重複使用的 schema 文件時，最好使用未繫結到任何特定結構位置的純名稱片段。這允許重新定位子 schema，而無需更新 JSON 指標參考。
為了指定此類子 schema 識別符，「$id」關鍵字會設定為帶有純名稱片段（而非 JSON 指標片段）的 URI 參考。此值必須以指定片段的井字號 ("#") 開頭，然後是一個字母 ([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 必須解釋為「$ref」參考。「$ref」屬性的值必須是 URI 參考。根據目前的 URI 基礎解析後，它會識別要使用的 schema 的 URI。 「$ref」物件中的所有其他屬性都必須忽略。
URI 不是網路定位器，而僅是識別符。如果 schema 是可透過網路存取的 URL，則它不一定需要從該位址下載，並且實作不應假設它們在遇到可透過網路存取的 URI 時應該執行網路操作。
schema 不得對 schema 執行無限迴圈。例如，如果兩個 schema「#alice」和「#bob」都具有指向另一個 schema 的「allOf」屬性，則天真的驗證器可能會陷入無限遞迴迴圈中，試圖驗證實例。schema 不應使用此類無限遞迴巢狀結構；行為是未定義的。
使用 URI 來識別遠端 schema 並不一定意味著會下載任何內容，而是 JSON Schema 實作應該事先了解它們將使用哪些 schema，以及識別它們的 URI。
當下載 schema 時，例如由通用使用者代理程式（在執行時間之前不知道要下載哪些 schema）下載時，請參閱 超媒體的用法 [hypermedia]。
實作應該能夠將任意 URI 與任意 schema 相關聯，和/或自動關聯 schema 的「$id」給定的 URI，這取決於驗證器對 schema 的信任程度。此類 URI 和 schema 可以在處理實例之前提供給實作，或者可以在處理時在 schema 文件中記錄，產生如 8.2.4 節中所示的關聯。
一個 schema 可能（並且很可能）有多個 URI，但沒有一種 URI 可以識別多個 schema。當多個 schema 試圖識別為相同的 URI 時，驗證器應引發錯誤情況。
可以使用已提供給它們的任何 URI 來識別 Schema，包括 JSON 指標或其「$id」直接給出的 URI。在所有情況下，取消參考「$ref」參考都需要首先根據 RFC 3986 [RFC3986]，將其值解析為相對於目前基礎 URI 的 URI 參考。
如果產生的 URI 識別目前文件中的 schema，或實作可用的另一個 schema 文件中的 schema，則應自動使用該 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 未知時，實作應該怎麼做？在哪些情況下允許自動網路取消參考？ 同源原則？ 可由使用者設定的選項？ 在由 Hyper-Schema 描述的不斷發展的 API 的情況下，預期會動態地將新的 schema 新增至系統，因此絕對要求預先載入 schema 文件是不可行的。
此關鍵字保留給 schema 作者對 schema 的讀者或維護者的註解。此關鍵字的值必須是字串。實作不得將此字串呈現給最終使用者。用於編輯 schema 的工具應該支援顯示和編輯此關鍵字。此關鍵字的值可用於旨在供開發人員使用的除錯或錯誤輸出。 Schema 詞彙表應允許在任何包含詞彙表關鍵字的物件中使用「$comment」。除非詞彙表明確禁止，否則實作可以假設允許使用「$comment」。詞彙表不得指定「$comment」超出此規格中所述的任何效果。將其他媒體類型或程式語言轉換為應用程式/schema+json 或從應用程式/schema+json 轉換的工具，可以選擇將該媒體類型或程式語言的原生註解轉換為「$comment」值或從「$comment」值轉換。當同時存在原生註解和「$comment」屬性時，此類轉換的行為取決於實作。實作應將「$comment」視為與未知的擴充關鍵字相同。它們可能會在處理期間的任何時間點剝離「$comment」值。特別是，這允許在部署的 schema 大小受到關注時縮短 schema。實作不得根據「$comment」屬性的存在、缺失或內容採取任何其他動作。
JSON 已被 HTTP 伺服器廣泛採用，用於自動化 API 和機器人。本節說明當與支援媒體類型和 Web 連結 [RFC8288] 的協定一起使用時，如何以更 RESTful 的方式增強 JSON 文件的處理。
建議由 schema 描述的實例使用連結關係「describedby」提供指向可下載 JSON Schema 的連結，如 連結資料協定 1.0，第 8.1 節 [W3C.REC-ldp-20150226] 中所定義。
在 HTTP 中，可以使用 Link 標頭 [RFC8288] 將此類連結附加到任何回應。此標頭的一個範例是
Link: <http://example.com/my-hyper-schema#>; rel="describedby"
媒體類型可以允許「schema」媒體類型參數，這使 HTTP 伺服器能夠根據 schema 執行 Content-Type 協商。媒體類型參數必須是以空格分隔的 URI 清單（即，相對參考無效）。
當使用媒體類型 application/schema-instance+json 時，必須提供「schema」參數。
schema URI 是不透明的，不應自動取消參考。如果實作不了解提供的 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 也可以在連結中傳送「schema」，儘管如果這完全取代媒體類型參數，可能會影響媒體類型語意和 Content-Type 協商
Link: </alice>;rel="schema", </bob>;rel="schema"
當用於網路上的超媒體系統時，HTTP [RFC7231] 通常是分發 schema 的首選協定。如果行為不當的用戶端比必要的頻繁地透過網路提取 schema，則可能會為伺服器維護人員帶來問題，而實際上可以長時間快取 schema。
HTTP 伺服器應在 JSON Schema 上設定長期快取標頭。HTTP 用戶端應觀察快取標頭，並且不應在其新鮮度期間內重新請求文件。分散式系統應使用共用快取和/或快取 Proxy。
User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
用戶端應設定或預先附加特定於 JSON Schema 實作或軟體產品的 User-Agent 標頭。由於符號依重要性的降序排列，因此 JSON Schema 程式庫名稱/版本應在更通用的 HTTP 程式庫名稱（如果有的話）之前。例如
用戶端應能夠使用「From」標頭發出請求，以便伺服器操作員可以聯絡可能行為不當的腳本的所有者。
綱要 (schemas) 和實例 (instances) 都是 JSON 值。因此，RFC 7159 [RFC7159] 中定義的所有安全性考量都適用。
實例和綱要通常由不受信任的第三方編寫，並部署在公共網際網路伺服器上。驗證器應注意，對綱要進行解析和驗證的過程不應消耗過多的系統資源。驗證器絕對不能陷入無限迴圈。
伺服器必須確保惡意方無法透過上傳具有已存在或非常相似的 "$id" 的綱要來變更現有綱要的功能。
個別 JSON 綱要詞彙也可能會有其自身的安全性考量。請參閱相關規格以取得更多資訊。
綱要作者應注意 "$comment" 的內容，因為惡意實作可能會違反規範將其顯示給最終使用者，或者如果預期會移除它們時卻未能移除。
惡意的綱要作者可能會在 "$comment" 中放置可執行程式碼或其他危險材料。實作絕對不能根據 "$comment" 的內容進行解析或採取其他動作。
JSON 綱要的建議 MIME 媒體類型定義如下
需要 JSON 綱要特定媒體類型的 JSON 綱要實例的建議 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", World Wide Web Consortium Recommendation 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., "片段識別碼和媒體類型定義的最佳實務", World Wide Web Consortium LastCall WD-fragid-best-practices-20121025, 2012 年 10 月。 |
| [json-schema-validation] | Wright, A., Andrews, H. 和 G. Luff, "JSON 綱要驗證：用於 JSON 結構驗證的詞彙", Internet-Draft draft-handrews-json-schema-validation-01, 2017 年 11 月。 |
| [json-hyper-schema] | Andrews, H. 和 A. Wright, "JSON 超綱要：用於 JSON 超媒體註解的詞彙", Internet-Draft draft-handrews-json-schema-hyperschema-01, 2017 年 11 月。 |
感謝 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 在 JSON 綱要的初始草案上的工作。
感謝 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch 和 Dave Finlay 為文件提供的提交和修補程式。
[CREF6]本節將在離開 Internet-Draft 狀態前移除。