| 網際網路工程任務組 | A. Wright, Ed. |
| 網路草案 | |
| 預期狀態：資訊性 | H. Andrews, Ed. |
| 截止日期：2018 年 9 月 20 日 | Cloudflare, Inc. |
| G. Luff | |
| 2018 年 3 月 19 日 |
JSON Schema 驗證：JSON 結構驗證的詞彙
draft-handrews-json-schema-validation-01
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) 的工作文件。請注意，其他群體也可能將工作文件作為網路草案發佈。目前網路草案的列表位於 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 Schema 核心 [json-schema] 規範所定義的概念、語法和術語。
本文件中「必須 (MUST)」、「不得 (MUST NOT)」、「必要 (REQUIRED)」、「應該 (SHALL)」、「不應該 (SHALL NOT)」、「應當 (SHOULD)」、「不應當 (SHOULD NOT)」、「建議 (RECOMMENDED)」、「可以 (MAY)」和「可選 (OPTIONAL)」等關鍵字應按照 RFC 2119 [RFC2119] 中的描述進行解釋。
本規範使用術語「容器實例」來指代陣列和物件實例。它使用術語「子實例」來指代陣列元素或物件成員值。
如果此陣列中沒有兩個元素是 相等 的 [json-schema]，則表示陣列值中的元素是唯一的。
JSON Schema 驗證會將綱要應用於實例內的位置，並對每個位置的資料結構斷言約束。然後，會使用任何包含非斷言資訊的關鍵字（例如描述性中繼資料和使用提示）來註釋滿足所有斷言約束的實例位置。如果實例內的所有位置都滿足所有斷言約束，則表示該實例對於綱要是有效的。
每個綱要物件都會針對它所適用的每個實例位置進行獨立評估。這大大簡化了驗證器的實作要求，確保它們不需要在整個文件驗證過程中維護狀態。
驗證首先將根綱要應用於完整的實例文件。從那裡開始，使用各種關鍵字來判斷哪些其他子綱要會應用於目前位置或子位置。這些關鍵字還定義了子綱要斷言結果是否以及如何修改和/或組合。這些關鍵字本身不會斷言條件。相反地，它們會控制如何應用和評估斷言。
本規範的 布林邏輯 [logic] 和 條件 [conditional] 部分中的關鍵字會將子綱要應用於與父綱要相同的位置。前者定義子綱要斷言結果的布林運算，而後者則評估一個子綱要，並使用其斷言結果來判斷還要應用哪兩個其他子綱要。
有幾個關鍵字會判斷哪些子綱要會應用於陣列項目、物件屬性值和物件屬性名稱。它們是：「items」、「additionalItems」、「contains」、「properties」、「patternProperties」、「additionalProperties」和「propertyNames」。 「contains」關鍵字僅要求其子綱要對於至少一個子實例有效，而其他關鍵字則要求所有子綱要對於它們所適用的所有子實例都有效。
驗證關鍵字通常獨立運作，而不會影響彼此的結果。
為了綱要作者的方便起見，在控制子綱要適用性的關鍵字中存在一些例外情況
驗證是檢查斷言的過程。每個斷言都會增加實例必須滿足的約束，才能成功驗證。
不存在的斷言關鍵字永遠不會限制驗證。在某些情況下，這種無操作行為與具有特定值的現有關鍵字相同，並且這些值會在已知時註明。
一般 [general]、數值 [numeric] 和 字串 [string] 部分中的所有關鍵字都是斷言，以及「minItems」、「maxItems」、「uniqueItems」、「minProperties」、「maxProperties」和「required」。此外，「dependencies」是條件和斷言關鍵字組合的簡寫。
「format」、「contentType」和「contentEncoding」關鍵字也可以作為斷言來實作，儘管該功能是本規範的可選部分，並且這些關鍵字傳達了其他非斷言資訊。
大多數驗證斷言僅限於特定基本型別中的值。當實例的型別不是關鍵字所針對的型別時，會認為實例符合斷言。
例如，「maxLength」關鍵字只會限制某些字串（太長）有效。如果實例是數字、布林值、空值、陣列或物件，則它對於此斷言是有效的。
除了斷言之外，本規範還提供一個小型中繼資料關鍵字詞彙表，可用於使用有用的資訊來註釋 JSON 實例。 第 7 節 和 第 8 節 關鍵字也可用作註釋，並且是可選的斷言，因為它們傳達了實例資料的其他使用指南。
一個適用於實例中特定位置的 schema，會根據該實例位置是否有效，將其註解附加到實例中的該位置。由於許多子 schema 可能適用於任何單一位置，註解關鍵字需要指定對具有不同值的多個適用關鍵字出現的任何不尋常處理方式。預設行為只是收集所有值。
額外的詞彙表應使用此機制，將它們自己的註解應用到實例。
當實例根據 schema 物件及其所有父 schema 有效時，就會收集註解。
特別是，在「not」中包含的子 schema 中的註解，無論深度為何，包括任何數量的額外「not」子 schema，都必須被忽略。如果實例根據「not」子 schema 有效，那麼根據定義，它對包含「not」的 schema 無效，因此不會使用「not」子 schema 的註解。
同樣地，即使實例成功地根據完整的 schema 文件驗證，也必須忽略「oneOf」、「anyOf」、「then」或「else」的失敗分支中的註解。
註解關鍵字必須應用於所有可能的子實例。即使僅在需要斷言評估時，此類應用可以被短路。例如，「contains」關鍵字只需要檢查斷言，直到至少有一個陣列項目證明是有效的。但是，當使用註解時，必須評估陣列中的所有項目，以確定所有應該與註解相關聯的項目。
應該注意的是，空字元 (\u0000) 在 JSON 字串中是有效的。要驗證的實例可能包含帶有此字元的字串值，無論底層程式語言是否有能力處理此類資料。
JSON 規範允許任意精度的數字，而 JSON Schema 不會增加任何此類限制。這表示 JSON Schema 處理的數值實例可以是任意大，或具有任意長的十進制部分，無論底層程式語言是否有能力處理此類資料。
兩個驗證關鍵字「pattern」和「patternProperties」使用正規表示式來表達約束，而「format」關鍵字的「regex」值會將實例值限制為正規表示式。這些正規表示式應根據 ECMA 262 [ecma262] 正規表示式方言有效。
此外，鑑於正規表示式結構支援的高度差異，schema 作者應將自己限制在以下正規表示式符記：
最後，實作方式不得將正規表示式視為已錨定，無論是在開頭還是結尾。這表示，例如，模式 "es" 符合 "expression"。
JSON Schema 驗證的目前 URI 為 <https://json-schema.dev.org.tw/draft-07/schema#>。
schema 中的驗證關鍵字會對成功驗證實例施加要求。
此關鍵字的值必須是字串或陣列。如果它是陣列，則陣列的元素必須是字串，且必須是唯一的。
字串值必須是六個原始類型 ("null"、"boolean"、"object"、"array"、"number" 或 "string") 之一，或是 "integer"，它符合任何小數部分為零的數字。
只有當實例位於此關鍵字所列出的任何集合中時，實例才會驗證。
此關鍵字的值必須是陣列。此陣列應至少有一個元素。陣列中的元素應是唯一的。
如果實例的值等於此關鍵字陣列值中的其中一個元素，則實例會針對此關鍵字成功驗證。
陣列中的元素可以是任何值，包括 null。
此關鍵字的值可以是任何類型，包括 null。
如果實例的值等於關鍵字的值，則實例會針對此關鍵字成功驗證。
「multipleOf」的值必須是數字，且嚴格大於 0。
只有當除以此關鍵字的值的結果是整數時，數值實例才有效。
「maximum」的值必須是數字，代表數值實例的包含上限。
如果實例是數字，則只有當實例小於或等於「maximum」時，此關鍵字才會驗證。
「exclusiveMaximum」的值必須是數字，代表數值實例的排除上限。
如果實例是數字，則只有當實例的值嚴格小於（不等於）「exclusiveMaximum」時，實例才有效。
「minimum」的值必須是數字，代表數值實例的包含下限。
如果實例是數字，則只有當實例大於或等於「minimum」時，此關鍵字才會驗證。
「exclusiveMinimum」的值必須是數字，代表數值實例的排除下限。
如果實例是數字，則只有當實例的值嚴格大於（不等於）「exclusiveMinimum」時，實例才有效。
此關鍵字的值必須是非負整數。
如果字串實例的長度小於或等於此關鍵字的值，則該實例會針對此關鍵字有效。
字串實例的長度定義為 RFC 7159 [RFC7159] 定義的字元數。
此關鍵字的值必須是非負整數。
如果字串實例的長度大於或等於此關鍵字的值，則該實例會針對此關鍵字有效。
字串實例的長度定義為 RFC 7159 [RFC7159] 定義的字元數。
省略此關鍵字的行為與值為 0 時相同。
此關鍵字的值必須是字串。此字串應是根據 ECMA 262 正規表示式方言有效的正規表示式。
如果正規表示式成功符合實例，則會認為字串實例有效。請回想一下：正規表示式不會隱式錨定。
「items」的值必須是有效的 JSON Schema 或有效的 JSON Schema 陣列。
此關鍵字決定了子實例如何驗證陣列，並且不會直接驗證直接實例本身。
如果「items」是 schema，則如果陣列中的所有元素都成功地根據該 schema 驗證，則驗證成功。
如果「items」是 schema 陣列，則如果實例的每個元素根據相同位置的 schema 驗證（如果有的話），則驗證成功。
省略此關鍵字的行為與空 schema 相同。
「additionalItems」的值必須是有效的 JSON Schema。
此關鍵字決定了子實例如何驗證陣列，並且不會直接驗證直接實例本身。
如果「items」是 schema 陣列，則如果位置大於「items」大小的每個實例元素根據「additionalItems」驗證，則驗證成功。
否則，「additionalItems」必須被忽略，因為「items」schema (可能是空 schema 的預設值) 會套用至所有元素。
省略此關鍵字的行為與空 schema 相同。
此關鍵字的值必須是非負整數。
如果陣列實例的大小小於或等於此關鍵字的值，則該實例會針對「maxItems」有效。
此關鍵字的值必須是非負整數。
如果陣列實例的大小大於或等於此關鍵字的值，則該實例會針對「minItems」有效。
省略此關鍵字的行為與值為 0 時相同。
此關鍵字的值必須是布林值。
如果此關鍵字具有布林值 false，則實例會成功驗證。如果它的布林值為 true，則如果實例的所有元素都是唯一的，則該實例會成功驗證。
省略此關鍵字的行為與值為 false 時相同。
此關鍵字的值必須是有效的 JSON Schema。
如果陣列實例的至少一個元素根據給定的 schema 有效，則該實例會針對「contains」有效。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數小於或等於此關鍵字的值，則該實例會針對「maxProperties」有效。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數大於或等於此關鍵字的值，則該實例會針對「minProperties」有效。
省略此關鍵字的行為與值為 0 時相同。
此關鍵字的值必須是陣列。此陣列的元素（如果有的話）必須是字串，且必須是唯一的。
如果陣列中的每個項目都是實例中屬性的名稱，則物件實例會針對此關鍵字有效。
省略此關鍵字的行為與空陣列相同。
「properties」的值必須為一個物件。此物件的每個值都必須是有效的 JSON Schema。
此關鍵字決定子實例如何針對物件進行驗證，並且不會直接驗證立即實例本身。
如果實例中出現的每個名稱，同時也作為此關鍵字值中的名稱出現，且該名稱的子實例成功地根據對應的 schema 進行驗證，則驗證成功。
省略此關鍵字的行為與空物件相同。
「patternProperties」的值必須為一個物件。此物件的每個屬性名稱都應該是有效的正規表示式，根據 ECMA 262 正規表示式方言。此物件的每個屬性值都必須是有效的 JSON Schema。
此關鍵字決定子實例如何針對物件進行驗證，並且不會直接驗證立即實例本身。針對此關鍵字的原始實例類型驗證總是成功。
如果每個與此關鍵字的值中作為屬性名稱出現的任何正規表示式匹配的實例名稱，其子實例都成功地針對每個與匹配的正規表示式相對應的 schema 進行驗證，則驗證成功。
省略此關鍵字的行為與空物件相同。
「additionalProperties」的值必須為有效的 JSON Schema。
此關鍵字決定子實例如何針對物件進行驗證，並且不會直接驗證立即實例本身。
「additionalProperties」的驗證僅適用於實例名稱的子值，這些子值不符合「properties」中的任何名稱，也不符合「patternProperties」中的任何正規表示式。
對於所有這類屬性，如果子實例根據「additionalProperties」schema 進行驗證，則驗證成功。
省略此關鍵字的行為與空 schema 相同。
如果實例是物件且包含特定屬性，則此關鍵字會指定要評估的規則。
此關鍵字的值必須是一個物件。每個屬性都指定一個依賴關係。每個依賴值都必須是一個陣列或有效的 JSON Schema。
如果依賴值是子 schema，且依賴鍵是實例中的屬性，則整個實例必須根據依賴值進行驗證。
如果依賴值是一個陣列，則陣列中的每個元素（如果有的話）都必須是字串，且必須是唯一的。如果依賴鍵是實例中的屬性，則依賴值中的每個項目都必須是實例中存在的屬性。
省略此關鍵字的行為與空物件相同。
「propertyNames」的值必須是有效的 JSON Schema。
如果實例是物件，如果實例中的每個屬性名稱都根據提供的 schema 進行驗證，則此關鍵字會進行驗證。請注意，schema 正在測試的屬性名稱始終會是字串。
省略此關鍵字的行為與空 schema 相同。
這些關鍵字共同作用，根據另一個子 schema 的結果，實作子 schema 的條件應用。
這些關鍵字不得跨子 schema 邊界相互作用。換句話說，「allOf」的一個分支中的「if」不得影響另一個分支中的「then」或「else」。
當這些關鍵字不存在時，沒有任何預設行為。特別是，它們不得被視為存在空 schema 的情況，且當「if」不存在時，「then」和「else」都必須完全被忽略。
此關鍵字的值必須是有效的 JSON Schema。
此關鍵字的子 schema 的驗證結果對整體驗證結果沒有直接影響。相反，它控制評估「then」或「else」關鍵字中的哪一個。
成功根據此關鍵字的子 schema 進行驗證的實例，也必須根據「then」關鍵字的子 schema 值（如果存在）進行驗證。
未能根據此關鍵字的子 schema 進行驗證的實例，也必須根據「else」關鍵字的子 schema 值（如果存在）進行驗證。
如果正在收集註釋[註釋]，則會以通常的方式從此關鍵字的子 schema 收集，包括當關鍵字存在但沒有「then」或「else」時。
此關鍵字的值必須是有效的 JSON Schema。
當「if」存在，且實例成功根據其子 schema 進行驗證時，如果實例也成功根據此關鍵字的子 schema 進行驗證，則針對此關鍵字的驗證成功。
當「if」不存在，或當實例未能根據其子 schema 進行驗證時，此關鍵字沒有任何作用。在這種情況下，為了驗證或註釋收集的目的，實作不得針對此關鍵字評估實例。
此關鍵字的值必須是有效的 JSON Schema。
當「if」存在，且實例未能根據其子 schema 進行驗證時，如果實例成功根據此關鍵字的子 schema 進行驗證，則針對此關鍵字的驗證成功。
當「if」不存在，或當實例成功根據其子 schema 進行驗證時，此關鍵字沒有任何作用。在這種情況下，為了驗證或註釋收集的目的，實作不得針對此關鍵字評估實例。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON Schema。
如果實例成功根據此關鍵字的值定義的所有 schema 進行驗證，則此實例會成功根據此關鍵字進行驗證。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON Schema。
如果實例成功根據此關鍵字的值定義的至少一個 schema 進行驗證，則此實例會成功根據此關鍵字進行驗證。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON Schema。
如果實例成功根據此關鍵字的值定義的正好一個 schema 進行驗證，則此實例會成功根據此關鍵字進行驗證。
此關鍵字的值必須是有效的 JSON Schema。
如果實例未能成功根據此關鍵字定義的 schema 進行驗證，則此實例會根據此關鍵字有效。
僅結構驗證可能不足以驗證實例是否滿足應用程式的所有需求。「format」關鍵字被定義為允許對透過權威資源（無論是 RFC 或其他外部規格）準確描述的固定值子集進行可互操作的語義驗證。
此關鍵字的值稱為格式屬性。它必須是字串。格式屬性通常只能驗證給定的實例類型集合。如果要驗證的實例類型不在此集合中，則此格式屬性和實例的驗證應成功。
「format」關鍵字既作為註釋（第 3.3 節），也作為斷言（第 3.2 節）發揮作用。雖然不需要特別的努力來將其作為傳達語義意義的註釋來實作，但實作驗證並非易事。
實作可能會支援將「format」關鍵字作為驗證斷言。如果他們選擇這樣做
實作可能會新增自訂格式屬性。除了當事方之間的協議外，schema 作者不應期望同儕實作支援此關鍵字和/或自訂格式屬性。
這些屬性適用於字串實例。
日期和時間格式名稱衍生自RFC 3339，第 5.6 節 [RFC3339]。
支援格式的實作應實作對以下屬性的支援
實作可能會使用該節中定義的其他產生式名稱支援額外屬性。如果實作了「full-date」或「full-time」，則必須實作對應的簡短形式（分別為「date」或「time」），且行為必須相同。實作不應使用任何與 RFC 3339 產生式匹配的名稱定義延伸屬性，除非它根據該產生式的規則進行驗證。[CREF2]目前對於支援所有 RFC 3339 格式的需求沒有共識，因此這種保留命名空間的方法將鼓勵實驗，而不會承諾整個集合。格式實作要求將在總體上變得更靈活，或者這些要求可能會被提升為完全指定的屬性或被刪除。
這些屬性適用於字串實例。
如果字串實例是有效的網際網路電子郵件地址，則該字串實例會根據以下這些屬性有效
請注意，所有根據「email」屬性有效的字串也根據「idn-email」屬性有效。
這些屬性適用於字串實例。
如果字串實例是網際網路主機名稱的有效表示法，則該字串實例會根據以下這些屬性有效
請注意，所有根據「hostname」屬性有效的字串也根據「idn-hostname」屬性有效。
這些屬性適用於字串實例。
如果字串實例是 IP 位址的有效表示法，則該字串實例會根據以下這些屬性有效
這些屬性適用於字串實例。
請注意，所有有效的 URI 都是有效的 IRI，且所有有效的 URI 參考也是有效的 IRI 參考。
此屬性適用於字串實例。
如果字串實例符合 [RFC6570] 的規範，是一個有效的 URI 範本 (任何層級)，則此字串實例符合此屬性。
請注意，URI 範本可用於 IRI；沒有單獨的 IRI 範本規格。
這些屬性適用於字串實例。
為了允許絕對和相對 JSON 指標，請使用 "anyOf" 或 "oneOf" 來表示支援任一種格式。
此屬性適用於字串實例。
一個正規表示式，根據 ECMA 262 [ecma262] 正規表示式方言，它應該是有效的。
驗證格式的實作必須至少接受本規範的正規表示式 [regexInterop] 章節中定義的 ECMA 262 子集，並且應該接受所有有效的 ECMA 262 表示式。
本節中定義的屬性表示實例包含編碼在 JSON 字串中的非 JSON 資料。它們描述內容的類型以及編碼方式。
這些屬性提供了將 JSON 資料解讀為豐富多媒體文件所需的額外資訊。
內容關鍵字既作為註釋(第 3.3 節)又作為斷言(第 3.2 節)發揮作用。雖然不需要特別努力將其作為註釋來傳達應用程式如何解釋字串中的資料，但實作媒體類型和編碼的一致性驗證並不容易。
實作可以支援 "contentMediaType" 和 "contentEncoding" 關鍵字作為驗證斷言。如果他們選擇這樣做，他們應該提供一個選項來禁用這些關鍵字的驗證。
如果實例值為字串，則此屬性定義應將該字串解釋為二進制資料，並使用此屬性命名的編碼進行解碼。RFC 2045 第 6.1 節 [RFC2045] 列出了此屬性的可能值。
此屬性的值必須為字串。
如果所描述的實例不是字串，則應忽略此屬性的值。
此屬性的值必須為媒體類型，如 RFC 2046 [RFC2046] 中所定義。此屬性定義此 schema 所定義的實例的媒體類型。
此屬性的值必須為字串。
如果所描述的實例不是字串，則應忽略此屬性的值。
如果 "contentEncoding" 屬性不存在，但實例值為字串，則此屬性的值應指定文字文件類型，並且字元集應為 JSON 字串值解碼成的字元集（預設為 Unicode）。
這是一個範例 schema，說明了 "contentEncoding" 和 "contentMediaType" 的用法
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
此 schema 描述的實例應為字串，並且它們的值應可解釋為 base64 編碼的 PNG 圖片。
另一個範例
{
"type": "string",
"contentMediaType": "text/html"
}
此 schema 描述的實例應為包含 HTML 的字串，使用 JSON 字串解碼成的任何字元集（預設為 Unicode）。
"definitions" 關鍵字為 schema 作者提供了一個標準化的位置，將可重複使用的 JSON Schema 内嵌到更通用的 schema 中。此關鍵字不會直接影響驗證結果。
此關鍵字的值必須是一個物件。此物件的每個成員值都必須是一個有效的 JSON Schema。
{
"type": "array",
"items": { "$ref": "#/definitions/positiveInteger" },
"definitions": {
"positiveInteger": {
"type": "integer",
"exclusiveMinimum": 0
}
}
}
例如，這是一個描述正整數陣列的 schema，其中正整數約束是 "definitions" 中的子 schema
Schema 驗證是一種有用的機制，用於使用額外資訊註釋實例資料。用於決定何時以及如何將註釋與實例關聯的規則在3.3節中概述。
這些通用註釋關鍵字提供了常用於文件和使用者介面顯示用途的資訊。它們並非旨在形成一套全面的功能。相反，可以為更複雜的基於註釋的應用程式定義額外的詞彙表。
這兩個關鍵字的值都必須是一個字串。
這兩個關鍵字都可用於使用有關此使用者介面產生的資料資訊來裝飾使用者介面。標題最好簡短，而描述將提供有關此 schema 描述的實例用途的解釋。
此關鍵字的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作應刪除重複項。
此關鍵字可用於提供與特定 schema 關聯的預設 JSON 值。建議預設值對於關聯的 schema 有效。
這些關鍵字的值必須為布林值。當這些關鍵字的多個實例適用於單個子實例時，如果任何實例指定 true 值，則結果值必須為 true，否則必須為 false。
如果 "readOnly" 的值為布林值 true，則表示實例的值由擁有權限的機構獨佔管理，並且應用程式嘗試修改此屬性的值預期會被該擁有權限的機構忽略或拒絕。
如果整個文件被標記為 "readOnly"，則在發送給擁有權限的機構時可能會被忽略，或者可能會導致錯誤，具體由該機構自行決定。
如果 "writeOnly" 的值為布林值 true，則表示從擁有權限的機構檢索實例時，該值永遠不會出現。當發送給擁有權限的機構以更新或建立文件（或其表示的資源）時，該值可以存在，但不會包含在任何更新或新建立的實例版本中。
如果整個文件被標記為 "writeOnly"，則檢索時可能會作為某種類型的空白文件返回，或者可能在檢索時產生錯誤，或者檢索請求被忽略，具體由該機構自行決定。
例如，"readOnly" 用於將資料庫產生的序號標記為唯讀，而 "writeOnly" 用於標記密碼輸入欄位。
這些關鍵字可用於輔助使用者介面實例產生。特別是，應用程式可能會選擇使用一個 widget，在輸入唯寫欄位時隱藏輸入值。
省略這些關鍵字的行為與 false 值相同。
此關鍵字的值必須是一個陣列。陣列中的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作必須提供所有值的扁平陣列，而不是陣列的陣列。
此關鍵字可用於提供與特定 schema 關聯的範例 JSON 值，以說明用法。建議這些值對於關聯的 schema 有效。
實作可能會使用 "default" 的值（如果存在）作為額外的範例。如果沒有 "examples"，仍然可以這樣使用 "default"。
JSON Schema 驗證定義了 JSON Schema 核心的詞彙表，並涉及其中列出的所有安全注意事項。
JSON Schema 驗證允許使用正規表示式，正規表示式有許多不同的（通常不相容的）實作。某些實作允許嵌入任意程式碼，這超出了 JSON Schema 的範圍，且絕對不允許。正規表示式通常也可以被設計成計算成本極高（具有所謂的「災難性回溯」），從而導致阻斷服務攻擊。
支援根據 "contentEncoding" 和/或 "contentMediaType" 驗證或以其他方式評估實例字串資料的實作，存在根據誤導性資訊以不安全的方式評估資料的風險。應用程式可以透過僅在建立 schema 和實例之間的關係時（例如，它們共享相同的權限）執行此類處理來降低此風險。
處理媒體類型或編碼時，會受到該媒體類型或編碼的安全注意事項的約束。例如，當處理在 JSON 字串中編碼的 JavaScript 或 ECMAScript 時，RFC 4329 指令碼媒體類型 [RFC4329] 的安全注意事項適用。
| [RFC2119] | Bradner, S., "在 RFC 中用於指示需求層級的關鍵字", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997 年 3 月。 |
| [RFC1034] | Mockapetris, P., "網域名稱 - 概念和設施", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1987 年 11 月。 |
| [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 月。 |
| [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 月。 |
| [RFC4291] | Hinden, R. 和 S. Deering, "IP 版本 6 定址架構", RFC 4291, DOI 10.17487/RFC4291, 2006 年 2 月。 |
| [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 月。 |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. 和 D. Orchard, "URI 模板", RFC 6570, DOI 10.17487/RFC6570, 2012 年 3 月。 |
| [RFC6531] | Yao, J. 和 W. Mao, "國際化電子郵件的 SMTP 擴充", RFC 6531, DOI 10.17487/RFC6531, 2012 年 2 月。 |
| [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 月。 |
| [ecma262] | ECMA 262 規範" |
| [relative-json-pointer] | Luff, G. 和 H. Andrews, "相對 JSON 指標", Internet-Draft draft-handrews-relative-json-pointer-01, 2017 年 11 月。 |
| [json-schema] | Wright, A. 和 H. Andrews, "JSON 綱要：用於描述 JSON 文件的媒體類型", Internet-Draft draft-handrews-json-schema-01, 2017 年 11 月。 |
| [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 對文件的提交和修補。
[CREF3]本節將在離開 Internet-Draft 狀態前刪除。