| 網際網路工程任務組 | A. Wright，編輯 |
| 網際網路草案 | |
| 預定狀態：資訊性 | H. Andrews，編輯 |
| 到期日：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）在本文發布之日生效的約束。請仔細檢閱這些文件，因為它們描述您對本文件的權利和限制。從本文件中提取的程式碼元件必須包含 Trust 法律條款第 4.e 節中描述的簡化 BSD 授權文字，並且如簡化 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」關鍵字只會限制某些字串（太長）為無效。如果實例是數字、布林值、null、陣列或物件，則它對於此斷言是有效的。
除了斷言之外，本規範還提供了一小組中繼資料關鍵字詞彙，可用於使用有用的資訊來註解 JSON 實例。第 7 節和第 8 節關鍵字也可用作註解以及作為可選斷言，因為它們傳達了實例資料的其他使用指南。
一個適用於實例中特定位置的綱要，若該實例位置符合該綱要，則會將其註解附加到實例中的該位置。由於許多子綱要可能適用於任何單一位置，註解關鍵字需要明確指定如何處理具有不同值的多個適用關鍵字。預設行為只是收集所有值。
額外的詞彙表應該使用此機制，將它們自己的註解應用到實例中。
每當實例根據綱要物件及其所有父綱要通過驗證時，都會收集註解。
特別是，在「not」中包含的子綱要中的註解，無論深度如何，包括任意數量的額外「not」子綱要，都必須被忽略。如果實例符合「not」子綱要，那麼根據定義，它不符合包含「not」的綱要，因此不會使用「not」子綱要的註解。
類似地，即使實例成功驗證整個綱要文件，「oneOf」、「anyOf」、「then」或「else」的失敗分支中的註解也必須被忽略。
註解關鍵字必須應用於所有可能的子實例。即使在只需要斷言評估時，此應用程式可以短路。例如，「contains」關鍵字只需檢查斷言，直到至少一個陣列項目證明有效。但是，當使用註解時，必須評估陣列中的所有項目，以確定應該將註解與哪些項目相關聯。
應注意，空字元 (\u0000) 在 JSON 字串中是有效的。要驗證的實例可能包含具有此字元的字串值，而不管底層程式語言處理此類資料的能力如何。
JSON 規範允許具有任意精度的數字，而 JSON Schema 沒有添加任何此類邊界。這意味著 JSON Schema 處理的數值實例可以任意大和/或具有任意長的十進位部分，而不管底層程式語言處理此類資料的能力如何。
兩個驗證關鍵字「pattern」和「patternProperties」使用正規表示式來表達約束，而「format」關鍵字的「regex」值將實例值限制為正規表示式。這些正規表示式應根據 ECMA 262 [ecma262] 正規表示式方言有效。
此外，考慮到正規表示式結構支援的高度差異，綱要作者應將自己限制於以下正規表示式符號
最後，實作程式不得將正規表示式視為錨定，無論是開頭還是結尾。例如，這表示模式「es」符合「expression」。
JSON Schema 驗證目前的 URI 是 <https://json-schema.dev.org.tw/draft-07/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 綱要或有效的 JSON 綱要的陣列。
此關鍵字決定子實例如何驗證陣列，並且不直接驗證立即實例本身。
如果「items」是綱要，則如果陣列中的所有元素都成功驗證該綱要，則驗證成功。
如果「items」是綱要的陣列，則如果實例的每個元素都驗證同一位置的綱要（如果有的話），則驗證成功。
省略此關鍵字的行為與空綱要相同。
「additionalItems」的值必須是有效的 JSON 綱要。
此關鍵字決定子實例如何驗證陣列，並且不直接驗證立即實例本身。
如果「items」是綱要的陣列，則如果位置大於「items」大小的每個實例元素都驗證「additionalItems」，則驗證成功。
否則，「additionalItems」必須被忽略，因為「items」綱要（可能是空綱要的預設值）會應用於所有元素。
省略此關鍵字的行為與空綱要相同。
此關鍵字的值必須是非負整數。
如果陣列實例的大小小於或等於此關鍵字的值，則該陣列實例符合「maxItems」的驗證。
此關鍵字的值必須是非負整數。
如果陣列實例的大小大於或等於此關鍵字的值，則該陣列實例符合「minItems」的驗證。
省略此關鍵字的行為與值 0 相同。
此關鍵字的值必須是布林值。
如果此關鍵字的布林值為 false，則實例會成功通過驗證。如果它的布林值為 true，則當其所有元素都是唯一的時，實例會成功通過驗證。
省略此關鍵字的行為與值 false 相同。
此關鍵字的值必須是有效的 JSON 綱要。
如果陣列實例的至少一個元素符合給定綱要的驗證，則該陣列實例符合「contains」的驗證。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量小於或等於此關鍵字的值，則該物件實例符合「maxProperties」的驗證。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量大於或等於此關鍵字的值，則該物件實例符合「minProperties」的驗證。
省略此關鍵字的行為與值 0 相同。
此關鍵字的值必須是陣列。此陣列的元素（如果有的話）必須是字串且必須是唯一的。
如果陣列中的每個項目都是實例中屬性的名稱，則物件實例符合此關鍵字的驗證。
省略此關鍵字的行為與空陣列相同。
「properties」的值必須是物件。此物件的每個值都必須是有效的 JSON 綱要。
此關鍵字決定子實例如何針對物件進行驗證，且不會直接驗證立即的實例本身。
如果實例中出現的每個名稱，同時也出現在此關鍵字的值中作為名稱，則該名稱的子實例成功通過對應的綱要驗證時，驗證即成功。
省略此關鍵字的行為與使用空物件相同。
「patternProperties」的值必須是一個物件。此物件的每個屬性名稱應該是根據 ECMA 262 正則表達式方言的有效正則表達式。此物件的每個屬性值必須是有效的 JSON 綱要。
此關鍵字決定子實例如何針對物件進行驗證，且不會直接驗證立即的實例本身。針對此關鍵字驗證基本實例類型總是會成功。
如果每個符合此關鍵字的值中作為屬性名稱出現的任何正則表達式的實例名稱，其子實例皆成功地通過與每個符合的正則表達式相對應的綱要驗證時，驗證即成功。
省略此關鍵字的行為與使用空物件相同。
「additionalProperties」的值必須是有效的 JSON 綱要。
此關鍵字決定子實例如何針對物件進行驗證，且不會直接驗證立即的實例本身。
使用「additionalProperties」進行驗證僅適用於實例名稱的子值，這些名稱不符合「properties」中的任何名稱，也不符合「patternProperties」中的任何正則表達式。
對於所有此類屬性，如果子實例通過「additionalProperties」綱要驗證，則驗證即成功。
省略此關鍵字的行為與空綱要相同。
此關鍵字指定如果實例是一個物件且包含某個屬性時，將會評估的規則。
此關鍵字的值必須是一個物件。每個屬性都指定一個相依性。每個相依性值必須是一個陣列或有效的 JSON 綱要。
如果相依性值是一個子綱要，且相依性鍵是實例中的屬性，則整個實例必須通過相依性值的驗證。
如果相依性值是一個陣列，則陣列中的每個元素（如果有的話）必須是字串，且必須是唯一的。如果相依性鍵是實例中的屬性，則相依性值中的每個項目都必須是實例中存在的屬性。
省略此關鍵字的行為與使用空物件相同。
「propertyNames」的值必須是有效的 JSON 綱要。
如果實例是一個物件，則如果實例中的每個屬性名稱都通過提供的綱要驗證，則此關鍵字驗證成功。請注意，綱要正在測試的屬性名稱將始終是一個字串。
省略此關鍵字的行為與空綱要相同。
這些關鍵字共同運作，根據另一個子綱要的結果實作子綱要有條件的套用。
這些關鍵字不得跨子綱要邊界相互影響。換句話說，「allOf」的一個分支中的「if」不得對另一個分支中的「then」或「else」產生影響。
當這些關鍵字不存在時，它們沒有預設行為。特別是，它們不得被視為存在於空綱要中，並且當不存在「if」時，「then」和「else」都必須完全被忽略。
此關鍵字的值必須是有效的 JSON 綱要。
此關鍵字的子綱要的驗證結果對整體驗證結果沒有直接影響。相反地，它控制評估哪個「then」或「else」關鍵字。
成功通過此關鍵字的子綱要驗證的實例，也必須通過「then」關鍵字的子綱要值（如果存在）的驗證。
未通過此關鍵字的子綱要驗證的實例，也必須通過「else」關鍵字的子綱要值（如果存在）的驗證。
如果正在收集註解 [annotations]，則會從此關鍵字的子綱要中以一般方式收集它們，包括當關鍵字存在而沒有「then」或「else」的情況。
此關鍵字的值必須是有效的 JSON 綱要。
當「if」存在，且實例成功通過其子綱要驗證時，如果實例也成功通過此關鍵字的子綱要驗證，則此關鍵字的驗證成功。
當「if」不存在，或當實例未通過其子綱要驗證時，此關鍵字無效。在此類情況下，無論是為了驗證還是註解收集，實作都不得根據此關鍵字評估實例。
此關鍵字的值必須是有效的 JSON 綱要。
當「if」存在，且實例未通過其子綱要驗證時，如果實例成功通過此關鍵字的子綱要驗證，則此關鍵字的驗證成功。
當「if」不存在，或當實例成功通過其子綱要驗證時，此關鍵字無效。在此類情況下，無論是為了驗證還是註解收集，實作都不得根據此關鍵字評估實例。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON 綱要。
如果實例成功通過此關鍵字的值定義的所有綱要驗證，則該實例將成功通過此關鍵字的驗證。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON 綱要。
如果實例成功通過此關鍵字的值定義的至少一個綱要驗證，則該實例將成功通過此關鍵字的驗證。
此關鍵字的值必須是非空陣列。陣列的每個項目都必須是有效的 JSON 綱要。
如果實例成功通過此關鍵字的值定義的剛好一個綱要驗證，則該實例將成功通過此關鍵字的驗證。
此關鍵字的值必須是有效的 JSON 綱要。
如果實例未成功通過此關鍵字定義的綱要驗證，則該實例對此關鍵字有效。
僅結構驗證可能不足以驗證實例是否符合應用程式的所有要求。「format」關鍵字定義為允許針對一組固定值進行可互操作的語意驗證，這些值可由權威資源（無論是 RFC 或其他外部規範）準確描述。
此關鍵字的值稱為格式屬性。它必須是一個字串。格式屬性通常只能驗證給定的一組實例類型。如果要驗證的實例類型不在這組中，則此格式屬性和實例的驗證應該會成功。
「format」關鍵字的功能是作為註解（第 3.3 節）和斷言（第 3.2 節）。雖然不需要特別努力將其作為傳達語意意義的註解來實作，但實作驗證並非易事。
實作可以將「format」關鍵字支援為驗證斷言。如果它們選擇這樣做
實作可以新增自訂格式屬性。除了當事方之間的協議之外，綱要作者不應期望同儕實作支援此關鍵字和/或自訂格式屬性。
這些屬性適用於字串實例。
日期和時間格式名稱衍生自 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 參考。
此屬性適用於字串實例。
如果一個字串實例是有效的 URI 範本（任何層級），則該實例符合此屬性，根據 [RFC6570] 的定義。
請注意，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] 所定義。此屬性定義此綱要所定義之實例的媒體類型。
此屬性的值必須是一個字串。
如果描述的實例不是字串，則應該忽略此屬性的值。
如果不存在 "contentEncoding" 屬性，但實例值是一個字串，則此屬性的值應該指定一個文字文件類型，並且字元集應該是 JSON 字串值被解碼成的字元集（預設為 Unicode）。
這是一個範例綱要，說明 "contentEncoding" 和 "contentMediaType" 的用法
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
此綱要描述的實例應該是字串，並且它們的值應該可以解釋為 base64 編碼的 PNG 圖片。
另一個範例
{
"type": "string",
"contentMediaType": "text/html"
}
此綱要描述的實例應該是包含 HTML 的字串，使用 JSON 字串解碼成的任何字元集（預設為 Unicode）。
"definitions" 關鍵字為綱要作者提供了一個標準化的位置，可將可重複使用的 JSON 綱要內嵌到更一般的綱要中。此關鍵字不會直接影響驗證結果。
此關鍵字的值必須是一個物件。此物件的每個成員值都必須是一個有效的 JSON 綱要。
{
"type": "array",
"items": { "$ref": "#/definitions/positiveInteger" },
"definitions": {
"positiveInteger": {
"type": "integer",
"exclusiveMinimum": 0
}
}
}
例如，這是一個描述正整數陣列的綱要，其中正整數約束是 "definitions" 中的一個子綱要
綱要驗證是一種有用的機制，可以用額外資訊註解實例資料。有關何時以及如何將註解與實例相關聯的規則在 3.3 節中概述。
這些通用的註解關鍵字提供了常用於文件和使用者介面顯示目的的資訊。它們並非旨在形成一套全面的功能。相反，可以為更複雜的基於註解的應用程式定義額外的詞彙表。
這兩個關鍵字的值都必須是一個字串。
這兩個關鍵字都可以用來裝飾使用者介面，以提供有關此使用者介面產生之資料的資訊。標題最好是簡短的，而描述將提供有關此綱要描述之實例用途的解釋。
此關鍵字的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作應該刪除重複項。
此關鍵字可用於提供與特定綱要關聯的預設 JSON 值。建議預設值對關聯的綱要是有效的。
這些關鍵字的值必須是一個布林值。當這些關鍵字的多個實例適用於單個子實例時，如果任何實例指定 true 值，則產生的值必須為 true，否則必須為 false。
如果 "readOnly" 的值為布林值 true，則表示實例的值由所有者權限獨家管理，並且應用程式嘗試修改此屬性的值時，預計會被該所有者權限忽略或拒絕。
如果整個文件被標記為 "readOnly"，則當將其傳送到所有者權限時，可以忽略它，或者可以根據該權限的決定而導致錯誤。
如果 "writeOnly" 的值為布林值 true，則表示從所有者權限檢索實例時永遠不會顯示該值。當傳送到所有者權限以更新或建立文件（或其代表的資源）時，它可以顯示，但不會包含在任何更新或新建立的實例版本中。
如果整個文件被標記為 "writeOnly"，則可能會以某種空白文件的形式傳回，或者可能會在檢索時產生錯誤，或者根據該權限的決定而忽略檢索請求。
例如，"readOnly" 將用於將資料庫產生的序號標記為唯讀，而 "writeOnly" 將用於標記密碼輸入欄位。
這些關鍵字可用於協助使用者介面實例產生。特別是，應用程式可以選擇使用一個小工具，該小工具在輸入時會隱藏僅寫入欄位的輸入值。
省略這些關鍵字與使用 false 值具有相同的行為。
此關鍵字的值必須是一個陣列。陣列中的值沒有限制。當此關鍵字的多個實例適用於單個子實例時，實作必須提供所有值的平面陣列，而不是陣列的陣列。
此關鍵字可用於提供與特定綱要關聯的範例 JSON 值，以說明其用法。建議這些值對關聯的綱要是有效的。
如果存在，實作可以使用 "default" 的值作為附加範例。如果不存在 "examples"，仍可以這種方式使用 "default"。
JSON 綱要驗證定義了 JSON 綱要核心的詞彙表，並涉及其中列出的所有安全考量。
JSON 綱要驗證允許使用正規表達式，它有許多不同的（通常不相容的）實作。某些實作允許嵌入任意程式碼，這超出了 JSON 綱要的範圍，並且絕對不允許。正規表達式也常常可以被設計為計算成本極高（所謂的「災難性回溯」），從而導致阻斷服務攻擊。
支援基於 "contentEncoding" 和/或 "contentMediaType" 驗證或以其他方式評估實例字串資料的實作，面臨根據誤導性資訊以不安全方式評估資料的風險。應用程式可以透過僅在綱要和實例之間建立關係（例如，它們共享相同的權限）時才執行此類處理來降低此風險。
處理媒體類型或編碼時，應遵循該媒體類型或編碼的安全考量。例如，當處理在 JSON 字串中編碼的 JavaScript 或 ECMAScript 時，適用 RFC 4329 Scripting Media Types [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 Schema：用於描述 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 Schema 的初始草案所做的工作。
感謝 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch、Dave Finlay 和 Denis Laxalde 對此文件的投稿和修補。