| 網際網路工程任務組 | A. Wright，編輯 |
| 網際網路草案 | |
| 意向狀態：資訊性 | H. Andrews，編輯 |
| 到期日：2020 年 3 月 20 日 | |
| B. Hutton，編輯 | |
| Wellcome Sanger 研究所 | |
| 2019 年 9 月 17 日 |
JSON Schema 驗證：用於 JSON 結構驗證的詞彙
draft-handrews-json-schema-validation-02
JSON Schema（application/schema+json）有多種用途，其中之一是 JSON 實例驗證。本文檔指定了一個 JSON Schema 的詞彙，用於描述 JSON 文件含義、為使用 JSON 資料的使用者介面提供提示，並對有效文件應有的外觀進行斷言。
本草案的問題列表可以在 <https://github.com/json-schema-org/json-schema-spec/issues> 中找到。
如需其他資訊，請參閱 <https://json-schema.dev.org.tw/>。
若要提供意見回饋，請使用此問題追蹤器、首頁上列出的通訊方式或以電子郵件傳送給文件編輯人員。
本網際網路草案的提交完全符合 BCP 78 和 BCP 79 的規定。
網際網路草案是網際網路工程任務組 (IETF) 的工作文件。請注意，其他群組也可能會將工作文件發佈為網際網路草案。目前網際網路草案的列表位於 https://datatracker.ietf.org/drafts/current/。
網際網路草案是有效期最多為六個月的草案文件，並且隨時可能會被其他文件更新、取代或廢棄。將網際網路草案用作參考資料或將其引述為「進行中的工作」以外的用途是不適當的。
本網際網路草案將於 2020 年 3 月 20 日到期。
版權所有 (c) 2019 IETF Trust 以及被識別為文件作者的人員。保留所有權利。
本文檔受 BCP 78 以及本文檔發佈之日生效的 IETF Trust 關於 IETF 文件之法律條款 (https://trustee.ietf.org/license-info) 的約束。請仔細審閱這些文件，因為它們描述了您對本文檔的權利和限制。從本文檔中提取的程式碼元件必須包含 Trust 法律條款第 4.e 節中描述的簡化 BSD 授權文字，並且在未提供簡化 BSD 授權中描述之擔保的情況下提供。
JSON Schema 可用於要求給定的 JSON 文件（實例）滿足一定數量的條件。這些條件是透過使用本規格中描述的關鍵字來斷言。此外，還定義了一組關鍵字來協助互動式使用者介面實例產生。
本規格將使用 JSON Schema 核心規格定義的概念、語法和術語。
本文檔中的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」應按照 RFC 2119 中的描述進行解釋。
本規格使用術語「容器實例」來指代陣列和物件實例。它使用術語「子實例」來指代陣列元素或物件成員值。
如果陣列的兩個元素不相等，則表示陣列值中的元素是唯一的。
JSON Schema 驗證會對實例資料的結構斷言約束。滿足所有斷言約束的實例位置會使用包含非斷言資訊的任何關鍵字進行註解，例如描述性後設資料和使用提示。如果實例中的所有位置都滿足所有斷言約束，則表示該實例根據綱要有效。
每個綱要物件都會根據其套用的每個實例位置獨立評估。這透過確保驗證程式不需要在整個文件範圍的驗證過程中維持狀態，大幅簡化了驗證程式的實作需求。
本規格定義了一組斷言關鍵字，以及一小組可以用來使用實用資訊註解 JSON 實例的後設資料關鍵字。第 7 節關鍵字主要用作註解，但也可以選擇用作斷言。第 8 節關鍵字是用於處理嵌入為 JSON 字串之文件的註解。
應注意，空字元 (\u0000) 在 JSON 字串中有效。無論底層程式語言處理此類資料的能力如何，要驗證的實例都可能包含帶有此字元的字串值。
JSON 規格允許具有任意精度的數字，而 JSON Schema 並未新增任何此類邊界。這表示 JSON Schema 處理的數值實例可以任意大和/或具有任意長的小數部分，而無論底層程式語言處理此類資料的能力如何。
使用正規表示式或將實例值限制為正規表示式的關鍵字受JSON Schema 核心規格中正規表示式的互通性考量約束。
預設 JSON Schema 後設綱要的目前 URI 是 <https://json-schema.dev.org.tw/draft/2019-09/schema>。為了方便綱要作者，此後設綱要描述了本規格和 JSON Schema 核心規格中定義的所有詞彙，以及兩個保留用於過渡期的舊關鍵字。下面每個章節都提供了個別詞彙和詞彙後設綱要 URI。某些詞彙是選擇性支援的，這在相關章節中有詳細說明。
詞彙和後設綱要 URI 可能會在規格草案之間發佈，以更正錯誤。實作應考慮在本規格草案之後和下一個草案之前日期出現的 URI，以表示與此處列出的語法和語義相同。
綱要中的驗證關鍵字會對成功驗證實例施加需求。這些關鍵字都是斷言，沒有任何註解行為。
不使用「$vocabulary」的後設綱要應被視為需要此詞彙，就好像其 URI 存在且值為 true 一樣。
此詞彙（稱為驗證詞彙）的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/vocab/validation>。
對應後設綱要的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/meta/validation>。
此關鍵字的值必須是字串或陣列。如果它是陣列，則陣列的元素必須是字串，並且必須是唯一的。
字串值必須是六種基本類型（「null」、「boolean」、「object」、「array」、「number」或「string」）之一，或是與任何小數部分為零的數字匹配的「integer」。
當且僅當實例在為此關鍵字列出的任何集合中時，實例才會進行驗證。
此關鍵字的值必須是陣列。此陣列應至少有一個元素。陣列中的元素應是唯一的。
如果實例的值等於此關鍵字陣列值中的其中一個元素，則該實例會針對此關鍵字成功進行驗證。
陣列中的元素可以是任何類型，包括 null。
此關鍵字的值可以是任何類型，包括 null。
使用此關鍵字在功能上等同於使用具有單一值的「enum」。
如果實例的值等於關鍵字的值，則該實例會針對此關鍵字成功進行驗證。
「multipleOf」的值必須是一個大於 0 的數字。
只有當數值實例除以此關鍵字的值，結果為整數時，該數值實例才有效。
「maximum」的值必須是一個數字，表示數值實例的包含上限。
如果實例是一個數字，則只有當實例小於或等於「maximum」時，此關鍵字才會驗證通過。
「exclusiveMaximum」的值必須是一個數字，表示數值實例的不包含上限。
如果實例是一個數字，則只有當實例的值嚴格小於（不等於）「exclusiveMaximum」時，該實例才有效。
「minimum」的值必須是一個數字，表示數值實例的包含下限。
如果實例是一個數字，則只有當實例大於或等於「minimum」時，此關鍵字才會驗證通過。
「exclusiveMinimum」的值必須是一個數字，表示數值實例的不包含下限。
如果實例是一個數字，則只有當實例的值嚴格大於（不等於）「exclusiveMinimum」時，該實例才有效。
此關鍵字的值必須是非負整數。
如果字串實例的長度小於或等於此關鍵字的值，則該字串實例對此關鍵字有效。
字串實例的長度定義為 RFC 8259 中定義的字元數。
此關鍵字的值必須是非負整數。
如果字串實例的長度大於或等於此關鍵字的值，則該字串實例對此關鍵字有效。
字串實例的長度定義為 RFC 8259 中定義的字元數。
省略此關鍵字的行為與值為 0 相同。
此關鍵字的值必須是一個字串。此字串應為有效的正規表示式，符合 ECMA 262 正規表示式方言。
如果正規表示式成功匹配實例，則認為字串實例有效。請注意：正規表示式不會隱式錨定。
此關鍵字的值必須是非負整數。
如果陣列實例的大小小於或等於此關鍵字的值，則該陣列實例對「maxItems」有效。
此關鍵字的值必須是非負整數。
如果陣列實例的大小大於或等於此關鍵字的值，則該陣列實例對「minItems」有效。
省略此關鍵字的行為與值為 0 相同。
此關鍵字的值必須是一個布林值。
如果此關鍵字的布林值為 false，則實例驗證成功。如果此關鍵字的布林值為 true，則當實例的所有元素都是唯一時，實例驗證成功。
省略此關鍵字的行為與值為 false 相同。
此關鍵字的值必須是非負整數。
如果符合 「contains」綱要的元素數量小於或等於此關鍵字的值，則該陣列實例對「maxContains」有效。
如果同一綱要物件中不存在「contains」，則此關鍵字無效。
此關鍵字的值必須是非負整數。
如果符合 「contains」綱要的元素數量大於或等於此關鍵字的值，則該陣列實例對「minContains」有效。
允許值為 0，但僅適用於將出現次數範圍設定為 0 到「maxContains」的值。值為 0 且沒有「maxContains」會導致「contains」始終通過驗證。
如果同一綱要物件中不存在「contains」，則此關鍵字無效。
省略此關鍵字的行為與值為 1 相同。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量小於或等於此關鍵字的值，則該物件實例對「maxProperties」有效。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量大於或等於此關鍵字的值，則該物件實例對「minProperties」有效。
省略此關鍵字的行為與值為 0 相同。
此關鍵字的值必須是一個陣列。此陣列的元素（如果有的話）必須是字串，且必須是唯一的。
如果陣列中的每個項目都是實例中屬性的名稱，則物件實例對此關鍵字有效。
省略此關鍵字的行為與空陣列相同。
此關鍵字的值必須是一個物件。此物件中的屬性（如果有的話）必須是陣列。每個陣列中的元素（如果有的話）必須是字串，且必須是唯一的。
此關鍵字指定如果存在特定的其他屬性，則為必要屬性。它們的必要性取決於其他屬性的存在。
如果每個同時出現在實例中和此關鍵字值中的名稱，其對應陣列中的每個項目也是實例中屬性的名稱，則驗證成功。
省略此關鍵字的行為與空物件相同。
單獨的結構驗證可能不足以讓應用程式正確使用某些值。「format」註解關鍵字的定義是為了讓綱要作者傳達透過權威資源（無論是 RFC 或其他外部規格）準確描述的固定值子集的語意資訊。
除了註解外，實作方式可能會將「format」視為斷言，並嘗試驗證值是否符合指定的語意。請參閱下方的實作需求以瞭解詳細資訊。
此關鍵字的值稱為格式屬性。它必須是一個字串。格式屬性通常只能驗證給定的一組實例類型。如果要驗證的實例類型不在這個集合中，則此格式屬性和實例的驗證應成功。本節中定義的所有格式屬性都適用於字串，但可以指定格式屬性以適用於 核心 JSON 綱要中定義的資料模型中定義的任何實例類型。[CREF1]請注意，本規範中的「type」關鍵字定義了資料模型中不包含的「integer」類型。因此，格式屬性可以限制為數字，但不限於整數。但是，數字格式可以與值為「integer」的「type」關鍵字一起使用，或者可以明確定義為當數字不是整數時始終通過，這會產生與僅應用於整數基本相同的行為。
未使用「$vocabulary」的中繼綱要應被視為使用此詞彙，就像其 URI 的值為 false 一樣。請參閱下方的實作需求以瞭解詳細資訊。
此詞彙（稱為格式詞彙）的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/vocab/format>。
對應中繼綱要的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/meta/format>。
「format」關鍵字的功能是註解，且可選擇作為斷言。[CREF2]這是由於該關鍵字的歷史因素，並不符合當前的關鍵字設計原則。為了管理此模糊性，如上所述，「format」關鍵字在其自身單獨的詞彙中定義。詞彙宣告的 true 或 false 值決定了處理使用「format」的綱要所需的實作需求，以及綱要作者可以依賴的行為。
如果實作支援註解收集，則必須收集格式值作為註解。這可在綱要驗證不可用或不足時啟用應用程式層級的驗證。
此需求不受詞彙宣告的布林值影響，也不受下一節中描述的「format」斷言行為設定影響。[CREF3]即使在以 false 值宣告詞彙時，也需要收集註解是非典型的，但為了確保即使在沒有實作斷言評估時，也可以執行應用程式層級驗證的最佳實務，這是必要的。由於「format」一直是此規範的一部分，因此即使在以 false 值宣告詞彙的情況下，也需要實作方式瞭解該關鍵字，這被認為不會造成負擔。
無論詞彙宣告的布林值為何，可以將「format」評估為斷言的實作方式，都必須提供啟用和停用此類評估的選項。當未明確指定選項時，斷言評估行為取決於詞彙宣告的布林值。
在實作整個規範時，此詞彙必須以 false 值支援（但請參閱下方的詳細資訊），並且可以 true 值支援。
當以 false 值宣告詞彙時，實作方式：[CREF4]這符合目前實作的現實情況，針對部分或所有格式屬性，實作方式提供的驗證層級差異很大，包括完全不進行驗證。這也是為了鼓勵僅依賴註解行為並在應用程式中執行語意驗證，這是建議的最佳實務。
當詞彙表宣告值為 true 時，支援此形式詞彙表的實作：[CREF5]預期對於簡單的格式，例如日期時間，語法驗證將會很徹底。對於複雜的格式，例如電子郵件地址，它是各種標準和隨著時間的推移進行的許多調整的合併，其中包含模糊和/或過時的規則，這些規則可能會或可能不會受到使用該值的其他應用程式的限制，因此最低限度的驗證就足夠了。例如，不包含 "@" 的實例字串顯然不是有效的電子郵件地址，並且包含 7 位元 ASCII 之外字元的「電子郵件」或「主機名稱」也同樣顯然無效。
由於許多屬性所涉及的複雜性，對於 format 屬性進行最低限度驗證的要求是刻意模糊且寬容的。請特別注意，該要求僅限於語法檢查；不應期望實作會發送電子郵件、嘗試連線到 URL，或以其他方式檢查 format 實例所識別的實體是否存在。
建議實作針對每個格式使用通用的剖析程式庫或著名的正規表示式。實作應清楚地記錄每個 format 屬性是如何驗證以及驗證到什麼程度。
標準核心和驗證元架構在其 "$vocabulary" 關鍵字中包含此詞彙表，值為 false，因為預設情況下，實作不需要將此關鍵字作為斷言支援。 以 true 值支援 format 詞彙表會大幅增加程式碼大小，在某些情況下會增加執行時間，並且並非所有實作都適用。
實作可以支援自訂的 format 屬性。除了各方之間的協議外，結構描述作者不應期望對等實作支援此類自訂 format 屬性。實作不得因未知的 format 屬性而導致驗證失敗或停止處理。當將「format」視為註釋時，實作應收集已知和未知的 format 屬性值。
詞彙表不支援針對關鍵字明確宣告不同的值集。由於此限制，以及此關鍵字歷史上的實作不均，如果需要互通性，建議在自訂詞彙表中定義其他關鍵字，而不是其他 format 屬性。
這些屬性適用於字串實例。
日期和時間格式名稱衍生自RFC 3339，第 5.6 節。持續時間格式來自 RFC 3339 附錄 A 中給出的 ISO 8601 ABNF。
支援格式的實作應實作對以下屬性的支援
實作可以支援使用該部分中定義的其他產生式名稱的其他屬性。如果實作了 "full-date" 或 "full-time"，則必須實作對應的短格式（分別為 "date" 或 "time"），且其行為必須相同。實作不應定義任何與 RFC 3339 產生式相符的名稱的擴充屬性，除非它根據該產生式的規則進行驗證。[CREF6]目前對於是否需要支援所有 RFC 3339 格式沒有共識，因此這種保留命名空間的方法將鼓勵實驗，而無需承諾支援整個集合。無論是格式實作要求總體上變得更靈活，還是這些格式可能會升級為完全指定的屬性或被刪除。
這些屬性適用於字串實例。
如果字串實例是有效的網際網路電子郵件地址，則該字串實例在這些屬性上有效，如下所示
請注意，所有對 "email" 屬性有效的字串也對 "idn-email" 屬性有效。
這些屬性適用於字串實例。
如果字串實例是網際網路主機名稱的有效表示法，則該字串實例在這些屬性上有效，如下所示
請注意，所有對 "hostname" 屬性有效的字串也對 "idn-hostname" 屬性有效。
這些屬性適用於字串實例。
如果字串實例是 IP 位址的有效表示法，則該字串實例在這些屬性上有效，如下所示
這些屬性適用於字串實例。
請注意，所有有效的 URI 都是有效的 IRI，並且所有有效的 URI 參考也是有效的 IRI 參考。
另請注意，「uuid」格式適用於純 UUID，而不是 URN 中的 UUID。範例是「f81d4fae-7dec-11d0-a765-00a0c91e6bf6」。對於作為 URN 的 UUID，請使用「uri」格式，並使用「pattern」正規表示式「^urn:uuid:」來表示 URI 配置和 URN 命名空間。
此屬性適用於字串實例。
如果字串實例是有效的 URI 範本（任何層級），根據[RFC6570]，則該字串實例在此屬性上有效。
請注意，URI 範本可用於 IRI；沒有單獨的 IRI 範本規範。
這些屬性適用於字串實例。
為了允許絕對和相對 JSON 指標，請使用 "anyOf" 或 "oneOf" 來表示支援任一格式。
此屬性適用於字串實例。
正規表示式，根據ECMA 262正規表示式方言應有效。
驗證格式的實作必須接受本規範的正規表示式章節中定義的 ECMA 262 的至少子集，並且應接受所有有效的 ECMA 262 表達式。
本節中定義的註釋表示實例包含以 JSON 字串編碼的非 JSON 資料。
這些屬性提供將 JSON 資料解讀為豐富多媒體文件所需的其他資訊。它們描述了內容的類型、其編碼方式和/或其驗證方式。它們不充當驗證斷言；格式錯誤的字串編碼文件不得導致包含的實例被視為無效。
不使用「$vocabulary」的後設綱要應被視為需要此詞彙，就好像其 URI 存在且值為 true 一樣。
此詞彙表（稱為內容詞彙表）的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/vocab/content>。
對應的元架構的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/meta/content>。
由於安全性與效能考量，以及可能內容類型的開放式性質，實作不得預設自動解碼、剖析和/或驗證字串內容。這另外也支援嵌入式文件的使用案例，這些文件旨在由處理包含文件的不同消費者處理。
本節中的所有關鍵字僅適用於字串，且對其他資料類型沒有影響。
實作可以提供自動解碼、剖析和/或驗證字串內容的功能。但是，它不得預設執行這些操作，並且必須將每個字串編碼文件的驗證結果與封閉文件分開提供。此過程應等同於完全評估原始架構的實例，然後使用註釋來解碼、剖析和/或驗證每個字串編碼文件。[CREF7]目前，從此類自動解碼、剖析和驗證功能執行和返回剖析資料和/或驗證結果的確切機制尚未指定。如果此類功能證明受歡迎，則可能會在未來的草案中更詳細地指定。
另請參閱安全性考量章節，以了解根據這些關鍵字自動處理實例字串可能引入的漏洞。
如果實例值是字串，則此屬性定義該字串應被解釋為二進位資料，並使用此屬性指定的編碼進行解碼。
此屬性的可能值列於 RFC 2045, Sec 6.1 和 RFC 4648 中。對於兩個 RFC 中都有定義的 "base64"，應使用 RFC 4648 中的定義，該定義取消了行長度限制，因為其他各種規範都規定了不同的長度。請注意，可以使用 "pattern" 關鍵字來約束字串中的行長度。
如果此關鍵字不存在，但存在 "contentMediaType"，則表示媒體類型可以像其他 JSON 字串值一樣編碼為 UTF-8，且不需要額外的解碼。
此屬性的值必須為字串。
如果實例是字串，則此屬性表示字串內容的媒體類型。如果存在 "contentEncoding"，則此屬性描述的是已解碼的字串。
此屬性的值必須為字串，且必須是 RFC 2046 中定義的媒體類型。
如果實例是字串，且存在 "contentMediaType"，則此屬性包含描述字串結構的 schema。
此關鍵字可以與任何可以映射到 JSON Schema 資料模型的媒體類型一起使用。
如果不存在 "contentMediaType"，則應忽略此屬性的值。
以下是一個範例 schema，說明 "contentEncoding" 和 "contentMediaType" 的用法
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
此 schema 所描述的實例預期為字串，並且它們的值應可解釋為 base64 編碼的 PNG 影像。
另一個範例
{
"type": "string",
"contentMediaType": "text/html"
}
此 schema 所描述的實例預期為包含 HTML 的字串，使用 JSON 字串解碼成的任何字元集。根據 RFC 8259 的 8.1 節，在完全封閉的系統之外，這必須是 UTF-8。
此範例描述了一個使用 HMAC SHA-256 演算法進行 MACed 的 JWT，並在其宣告集中需要 "iss" 和 "exp" 欄位。
{
"type": "string",
"contentMediaType": "application/jwt",
"contentSchema": {
"type": "array",
"minItems": 2,
"items": [
{
"const": {
"typ": "JWT",
"alg": "HS256"
}
},
{
"type": "object",
"required": ["iss", "exp"],
"properties": {
"iss": {"type": "string"},
"exp": {"type": "integer"}
}
}
]
}
}
請注意，"contentEncoding" 沒有出現。雖然 "application/jwt" 媒體類型使用 base64url 編碼，但這是由媒體類型定義的，它決定了如何將 JWT 字串解碼為兩個 JSON 資料結構的清單：首先是標頭，然後是有效負載。由於 JWT 媒體類型確保 JWT 可以用 JSON 字串表示，因此不需要進一步的編碼或解碼。
這些通用註釋關鍵字提供了常用於文件和使用者介面顯示目的的資訊。它們並非旨在形成一套全面的功能。相反，可以為更複雜的基於註釋的應用程式定義其他詞彙表。
不使用「$vocabulary」的後設綱要應被視為需要此詞彙，就好像其 URI 存在且值為 true 一樣。
此詞彙表（稱為中繼資料詞彙表）的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/vocab/meta-data>。
對應的中繼 schema 的目前 URI 為：<https://json-schema.dev.org.tw/draft/2019-09/meta/meta-data>。
這兩個關鍵字的值都必須是字串。
這兩個關鍵字都可用於使用有關此使用者介面產生的資料的資訊來修飾使用者介面。標題最好簡短，而描述將提供有關此 schema 所描述的實例的用途的說明。
此關鍵字的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作應移除重複項。
此關鍵字可用於提供與特定 schema 相關聯的預設 JSON 值。建議預設值對於相關的 schema 有效。
此關鍵字的值必須為布林值。當此關鍵字的多個實例適用於單個子實例時，如果任何實例指定 true 值，則應用程式應將該實例位置視為已棄用。
如果 "deprecated" 的值為布林值 true，則表示應用程式應避免使用宣告的屬性。這可能表示該屬性將在未來被移除。
包含 "deprecated" 且值為 true 的根 schema 表示整個被描述的資源可能會在未來被移除。
當通過 "items" 將 "deprecated" 關鍵字應用於陣列中的項目時，如果 "items" 是單個 schema，則棄用與整個陣列有關；如果 "items" 是 schema 的陣列，則棄用與根據子 schema 位置的相應項目有關。
省略此關鍵字的行為與值為 false 相同。
這些關鍵字的值必須為布林值。當這些關鍵字的多個實例適用於單個子實例時，如果任何實例指定 true 值，則結果行為應與 true 值相同；否則，應與 false 值相同。
如果 "readOnly" 的值為布林值 true，則表示實例的值完全由擁有權限的機構管理，並且應用程式嘗試修改此屬性值的操作預期會被該擁有權限的機構忽略或拒絕。
如果將整個文件標記為 "readOnly"，則如果將其發送到擁有權限的機構，可能會被忽略，或者可能會導致錯誤，這由該機構自行決定。
如果 "writeOnly" 的值為布林值 true，則表示從擁有權限的機構檢索實例時，該值永遠不存在。當發送到擁有權限的機構以更新或建立文件（或其代表的資源）時，該值可能存在，但它不會包含在實例的任何更新或新建立的版本中。
如果將整個文件標記為 "writeOnly"，則可能會將其返回為某種空白文件，或者在檢索時可能會產生錯誤，或者可能會忽略檢索請求，這由該機構自行決定。
例如，"readOnly" 可用於將資料庫產生的序號標記為唯讀，而 "writeOnly" 可用於將密碼輸入欄位標記為僅寫入。
這些關鍵字可用於協助使用者介面實例產生。特別是，應用程式可能會選擇使用一個小工具，該小工具會隱藏僅寫入欄位在輸入時的值。
省略這些關鍵字的行為與 false 值相同。
此關鍵字的值必須是一個陣列。陣列中的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作必須提供所有值的扁平陣列，而不是陣列的陣列。
此關鍵字可用於提供與特定 schema 相關聯的範例 JSON 值，以說明用法。建議這些值對於相關的 schema 有效。
如果存在，實作可能會使用 "default" 的值作為額外的範例。如果不存在 "examples"，則仍可以這種方式使用 "default"。
JSON Schema 驗證定義了 JSON Schema 核心的詞彙表，並涉及其中列出的所有安全性考量。
JSON Schema 驗證允許使用正則表達式，它有許多不同的（通常不相容的）實作。某些實作允許嵌入任意程式碼，這超出了 JSON Schema 的範圍，並且絕對不能允許。正則表達式通常也可以被設計為計算起來非常昂貴（具有所謂的「災難性回溯」），從而導致阻斷服務攻擊。
支援基於 "contentEncoding" 和/或 "contentMediaType" 驗證或以其他方式評估實例字串資料的實作，存在基於誤導性資訊以不安全的方式評估資料的風險。應用程式可以透過僅在 schema 和實例之間建立關係（例如，它們共享相同的權限）時才執行此類處理來降低此風險。
處理媒體類型或編碼會受到該媒體類型或編碼的安全性考量的約束。例如，當處理 JSON 字串中編碼的 JavaScript 或 ECMAScript 時，適用 RFC 4329 指令碼媒體類型的安全性考量。
| [ecma262] | "ECMA 262 規格" |
| [json-schema] | Wright, A. 和 H. Andrews，"JSON Schema: A Media Type for Describing JSON Documents"，Internet-Draft draft-handrews-json-schema-02，2017 年 11 月。 |
| [relative-json-pointer] | Luff, G. 和 H. Andrews，"Relative JSON Pointers"，Internet-Draft draft-handrews-relative-json-pointer-01，2017 年 11 月。 |
| [RFC1123] | Braden, R.，"網際網路主機需求 - 應用程式和支援"，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989 年 10 月。 |
| [RFC2045] | Freed, N. 和 N. Borenstein，"多用途網際網路郵件擴充功能 (MIME) 第一部分：網際網路訊息主體的格式"，RFC 2045，DOI 10.17487/RFC2045，1996 年 11 月。 |
| [RFC2046] | Freed, N. 和 N. Borenstein，"多用途網際網路郵件擴充功能 (MIME) 第二部分：媒體類型"，RFC 2046，DOI 10.17487/RFC2046，1996 年 11 月。 |
| [RFC2119] | Bradner, S.，"在 RFC 中用於表示需求層級的關鍵字"，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [RFC2673] | Crawford, M.，"網域名稱系統中的二進位標籤"，RFC 2673，DOI 10.17487/RFC2673，1999 年 8 月。 |
| [RFC3339] | Klyne, G. 和 C. Newman，"網際網路上的日期和時間：時間戳記"，RFC 3339，DOI 10.17487/RFC3339，2002 年 7 月。 |
| [RFC3986] | Berners-Lee, T.、Fielding, R. 和 L. Masinter，"統一資源識別碼 (URI)：通用語法"，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月。 |
| [RFC3987] | Duerst, M. 和 M. Suignard，"國際化資源識別碼 (IRI)"，RFC 3987，DOI 10.17487/RFC3987，2005 年 1 月。 |
| [RFC4122] | Leach, P.、Mealling, M. 和 R. Salz，"通用唯一識別碼 (UUID) URN 命名空間"，RFC 4122，DOI 10.17487/RFC4122，2005 年 7 月。 |
| [RFC4291] | Hinden, R. 和 S. Deering，"IP 版本 6 定址架構"，RFC 4291，DOI 10.17487/RFC4291，2006 年 2 月。 |
| [RFC4648] | Josefsson, S.，"Base16、Base32 和 Base64 資料編碼"，RFC 4648，DOI 10.17487/RFC4648，2006 年 10 月。 |
| [RFC5322] | Resnick, P.，"網際網路訊息格式"，RFC 5322，DOI 10.17487/RFC5322，2008 年 10 月。 |
| [RFC5890] | Klensin, J.，"應用程式的國際化網域名稱 (IDNA)：定義和文件架構"，RFC 5890，DOI 10.17487/RFC5890，2010 年 8 月。 |
| [RFC5891] | Klensin, J.，"應用程式的國際化網域名稱 (IDNA)：協定"，RFC 5891，DOI 10.17487/RFC5891，2010 年 8 月。 |
| [RFC6531] | Yao, J. 和 W. Mao，"用於國際化電子郵件的 SMTP 擴充功能"，RFC 6531，DOI 10.17487/RFC6531，2012 年 2 月。 |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. 和 D. Orchard, "URI 模板", RFC 6570, DOI 10.17487/RFC6570, 2012 年 3 月。 |
| [RFC6901] | Bryan, P., Zyp, K. 和 M. Nottingham, "JavaScript 物件表示法 (JSON) 指標", RFC 6901, DOI 10.17487/RFC6901, 2013 年 4 月。 |
| [RFC8259] | Bray, T., "JavaScript 物件表示法 (JSON) 資料交換格式", STD 90, RFC 8259, DOI 10.17487/RFC8259, 2017 年 12 月。 |
| [RFC4329] | Hoehrmann, B., "指令碼媒體類型", RFC 4329, DOI 10.17487/RFC4329, 2006 年 4 月。 |
自此草案起，已有多個關鍵字從本文移至核心規格中，在某些情況下，關鍵字已重新命名或進行其他變更。這會影響以下先前的驗證關鍵字
感謝 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 和 Denis Laxalde 對於本文檔的提交和修補。
[CREF8]此章節在離開 Internet-Draft 狀態前將會移除。