| 網際網路工程任務組 | A. Wright, 編 |
| 網際網路草案 | |
| 預定狀態：資訊性 | H. Andrews, 編 |
| 到期日：2021 年 8 月 1 日 | |
| B. Hutton, 編 | |
| 2020 年 1 月 28 日 |
JSON Schema 驗證：JSON 結構驗證的詞彙表
draft-bhutton-json-schema-validation-00
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/。
網際網路草案是有效期最多六個月的草案文件，隨時可能被其他文件更新、取代或廢棄。將網際網路草案作為參考資料或以「工作中」以外的方式引用是不恰當的。
本網際網路草案將於 2021 年 8 月 1 日到期。
版權所有 © 2020 IETF Trust 和被認定為文件作者的人員。保留所有權利。
本文件受 BCP 78 和 IETF Trust 的 IETF 文件相關法律條款 (https://trustee.ietf.org/license-info) 的約束，這些條款在本文件發佈之日生效。請仔細審閱這些文件，因為其中描述您關於本文件的權利和限制。從本文件中提取的程式碼元件必須包含「簡化 BSD 授權」文字，如「信託法律條款」第 4.e 節所述，且不提供「簡化 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/2020-12/schema>。為了方便架構作者，此元架構描述了一種方言，該方言由本規範和 JSON Schema 核心規範中定義的所有詞彙表，以及兩個保留用於過渡期的前關鍵字組成。每個章節都提供了個別詞彙表和詞彙表元架構 URI。某些詞彙表是可選的，詳細說明在相關章節中說明。
為了更正錯誤，可能會在規格草案之間發佈更新的詞彙表和元架構 URI。實作應考慮將本規範草案之後且在下一個規格草案之前日期的 URI，以表示與此處列出的語法和語義相同。
架構中的驗證關鍵字會對實例的成功驗證施加要求。這些關鍵字都是斷言，沒有任何註解行為。
不使用「$vocabulary」的元架構應被視為要求此詞彙表，如同其 URI 存在且值為 true 一樣。
此詞彙表 (稱為「驗證」詞彙表) 的目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/vocab/validation>。
對應的元模式目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/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 時相同。
此關鍵字的值必須是非負整數。
如果相同的 schema 物件中不存在 "contains"，則此關鍵字無效。
實例陣列針對 "maxContains" 有效的方式有兩種，具體取決於相鄰 "contains" 關鍵字的註釋結果形式。第一種方式是如果註釋結果是陣列，並且該陣列的長度小於或等於 "maxContains" 值。第二種方式是如果註釋結果是布林值 "true"，並且實例陣列長度小於或等於 "maxContains" 值。
此關鍵字的值必須是非負整數。
如果相同的 schema 物件中不存在 "contains"，則此關鍵字無效。
實例陣列針對 "minContains" 有效的方式有兩種，具體取決於相鄰 "contains" 關鍵字的註釋結果形式。第一種方式是如果註釋結果是陣列，並且該陣列的長度大於或等於 "minContains" 值。第二種方式是如果註釋結果是布林值 "true"，並且實例陣列長度大於或等於 "minContains" 值。
允許值為 0，但僅用於將出現次數範圍設定為 0 到 "maxContains" 的值。在沒有 "maxContains" 的情況下，值為 0 會導致 "contains" 始終通過驗證。
省略此關鍵字的行為與值為 1 時相同。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量小於或等於此關鍵字的值，則該實例針對 "maxProperties" 有效。
此關鍵字的值必須是非負整數。
如果物件實例的屬性數量大於或等於此關鍵字的值，則該實例針對 "minProperties" 有效。
省略此關鍵字的行為與值為 0 時相同。
此關鍵字的值必須是陣列。此陣列中的元素（如果有的話）必須是字串，且必須是唯一的。
如果陣列中的每個項目都是實例中屬性的名稱，則該物件實例針對此關鍵字有效。
省略此關鍵字的行為與空陣列相同。
此關鍵字的值必須是物件。此物件中的屬性（如果有的話）必須是陣列。每個陣列中的元素（如果有的話）必須是字串，且必須是唯一的。
此關鍵字指定如果存在特定其他屬性時，則必須存在的屬性。它們的要求取決於其他屬性的存在。
如果出現在實例中以及此關鍵字值中的名稱的每個名稱，其對應的陣列中的每個項目也是實例中屬性的名稱，則驗證成功。
省略此關鍵字的行為與空物件相同。
僅憑結構驗證可能不足以讓應用程式正確利用某些值。"format" 註解關鍵字被定義為允許 schema 作者傳達對於權威資源（無論是 RFC 或其他外部規格）準確描述的固定值子集的語意資訊。
此關鍵字的值稱為格式屬性。它必須是字串。格式屬性通常只能驗證給定的一組實例類型。如果要驗證的實例類型不在這組中，則此格式屬性和實例的驗證應成功。本節中定義的所有格式屬性都適用於字串，但可以指定格式屬性以應用於 核心 JSON Schema 中定義的資料模型中定義的任何實例類型。[CREF1]請注意，此規格中的 "type" 關鍵字定義了一個不屬於資料模型的 "integer" 類型。因此，格式屬性可以限制為數字，但不能特別限制為整數。但是，數值格式可以與值為 "integer" 的 "type" 關鍵字一起使用，或者可以明確定義為當數字不是整數時始終通過，這會產生與僅應用於整數基本相同的行為。
此詞彙表（稱為 Format-Annotation 詞彙表）的目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/vocab/format-annotation>。對應的元模式目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/meta/format-annotation>。實作對此詞彙表的支持是必需的。
除了 Format-Annotation 詞彙表之外，還有一個次要詞彙表可用於自訂元模式，該元模式將 "format" 定義為斷言。Format-Assertion 詞彙表的 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/vocab/format-assertion>。對應的元模式目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/meta/format-assertion>。實作對 Format-Assertion 詞彙表的支持是可選的。
指定 Format-Annotation 和 Format-Assertion 詞彙表在功能上等同於僅指定 Format-Assertion 詞彙表，因為它的要求是 Format-Annotation 詞彙表的超集。
"format" 關鍵字的功能由參考的詞彙表定義。
如果實作支援註解收集，則必須將 format 的值收集為註解。這可以在 schema 驗證不可用或不足時啟用應用程式層級的驗證。
除了註解之外，實作可能仍然將 "format" 視為斷言，並嘗試驗證值是否符合指定的語意。實作必須提供選項來啟用和停用此類評估，並且預設必須停用。實作應記錄其對此類驗證的支援程度。[CREF2]由於在未指定 Format-Assertion 詞彙表時，實作不需提供完整的驗證支援，因此指定 Format-Annotation 詞彙表並在實作中啟用驗證不應視為等同於指定 Format-Assertion 詞彙表。
當實作設定為斷言行為時，它：[CREF3]這符合目前實作的現況，對於某些或所有格式屬性，它們提供差異很大的驗證程度，包括完全不驗證。此設計也鼓勵僅依賴註解行為並在應用程式中執行語意驗證，這是建議的最佳實務。
當格式斷言詞彙宣告為 true 值時，實作**必須**為本規範定義的所有格式提供完整的驗證支援。無法提供完整驗證支援的實作**必須**拒絕處理該 schema。
由於許多屬性涉及的複雜性，對格式屬性進行最少驗證的要求是故意模糊且寬容的。請特別注意，此要求僅限於語法檢查；不應期望實作會發送電子郵件、嘗試連線到 URL，或以其他方式檢查由格式實例識別的實體是否存在。
建議實作為每個格式使用通用的剖析程式庫或廣為人知的正規表示式。實作**應該**清楚地記錄每個格式屬性如何以及在何種程度上進行驗證。
標準核心和驗證 meta-schema在其 "$vocabulary" 關鍵字中以 false 值包含此詞彙，因為預設情況下，不要求實作支援此關鍵字作為斷言。以 true 值支援格式詞彙被認為會大幅增加程式碼大小，在某些情況下會增加執行時間，因此不適用於所有實作。
實作可以支援自訂格式屬性。除了各方之間的協議外，schema 作者**不應**期望對等實作支援此類自訂格式屬性。實作**不得**在收集未知格式時失敗，將其作為註解收集。當指定格式斷言詞彙時，實作**必須**在遇到未知格式時失敗。
詞彙不支援專門為關鍵字宣告不同的值集合。由於此限制，以及此關鍵字在歷史上實作不均，如果需要互通性，建議在自訂詞彙中定義其他關鍵字，而不是其他格式屬性。
這些屬性適用於字串實例。
日期和時間格式名稱衍生自 RFC 3339，第 5.6 節。持續時間格式來自 RFC 3339 附錄 A 中給出的 ISO 8601 ABNF。
支援格式的實作**應該**實作對以下屬性的支援
實作**可以**支援使用該 RFC 中任何地方定義的其他產生式名稱的其他屬性。如果實作 "full-date" 或 "full-time"，則**必須**實作對應的簡短形式（分別為 "date" 或 "time"），且行為**必須**相同。實作**不應**定義任何符合 RFC 3339 產生式名稱的擴充屬性，除非它根據該產生式的規則進行驗證。[CREF5]目前對於是否需要支援所有 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" 格式，並使用 "^urn:uuid:" 的 "pattern" 正規表示式來指示 URI 方案和 URN 命名空間。
此屬性適用於字串實例。
如果字串實例是根據 [RFC6570] 的有效 URI 範本（任何層級），則它對於此屬性有效。
請注意，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/2020-12/vocab/content>。
對應 meta-schema 的目前 URI 為：<https://json-schema.dev.org.tw/draft/2020-12/meta/content>。
由於安全性和效能考量，以及可能內容類型的開放性，實作**不應**預設自動解碼、解析和/或驗證字串內容。此外，這也支援嵌入式文件的使用案例，這些文件旨在由與處理包含文件的消費者不同的消費者進行處理。
本節中的所有關鍵字僅適用於字串，對其他資料類型沒有影響。
實作**可以**提供自動解碼、解析和/或驗證字串內容的功能。但是，**不應**預設執行這些操作，並且**必須**將每個字串編碼文件的驗證結果與封閉的文件分開提供。此過程**應該**等同於針對原始 Schema 完全評估實例，然後使用註釋來解碼、解析和/或驗證每個字串編碼的文件。[CREF6]目前，關於執行和從此自動解碼、解析和驗證功能返回已解析資料和/或驗證結果的確切機制尚未指定。如果此功能證明受歡迎，則可能會在未來的草案中更詳細地指定。
另請參閱安全考量章節，了解根據這些關鍵字自動處理實例字串可能引入的漏洞。
如果實例值是一個字串，此屬性定義該字串**應該**被解釋為二進位資料，並使用此屬性所命名的編碼進行解碼。
RFC 4648 列出了指示 base 16、32 和 64 編碼以及幾種變體值的可能值。此外，RFC 2045 的 6.7 和 6.8 節提供了 MIME 中使用的編碼。由於 "base64" 在兩個 RFC 中都有定義，除非該字串明確用於 MIME 上下文中，否則**應該**採用 RFC 4648 中的定義。請注意，所有這些編碼都會產生僅由 7 位 ASCII 字元組成的字串。因此，此關鍵字對於包含該範圍之外字元的字串沒有意義。
如果缺少此關鍵字，但存在 "contentMediaType"，則表示編碼是恆等編碼，也就是說，為了以 UTF-8 字串表示內容，不需要進行轉換。
此屬性的值**必須**是字串。
如果實例是一個字串，此屬性表示字串內容的媒體類型。如果存在 "contentEncoding"，則此屬性描述已解碼的字串。
此屬性的值**必須**是字串，該字串**必須**是媒體類型，如 RFC 2046 所定義。
如果實例是一個字串，且存在 "contentMediaType"，則此屬性包含一個描述字串結構的 Schema。
此關鍵字**可以**與任何可以映射到 JSON 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,
"prefixItems": [
{
"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/2020-12/vocab/meta-data>。
相應的元 Schema 的當前 URI 是：<https://json-schema.dev.org.tw/draft/2020-12/meta/meta-data>。
這兩個關鍵字的值**必須**是字串。
這兩個關鍵字都可以用來裝飾使用者介面，提供有關此使用者介面產生資料的資訊。標題最好簡短，而描述將提供有關此 Schema 所描述實例用途的解釋。
對此關鍵字的值沒有限制。當此關鍵字的多個出現適用於單個子實例時，實作**應該**移除重複項。
此關鍵字可用於提供與特定 Schema 關聯的預設 JSON 值。建議預設值對於相關的 Schema 而言是有效的。
此關鍵字的值**必須**是布林值。當此關鍵字的多個出現適用於單個子實例時，如果任何出現指定了 true 值，則應用程式**應該**認為該實例位置已棄用。
如果 "deprecated" 的值為布林值 true，則表示應用程式**應該**避免使用宣告的屬性。這**可能**意味著該屬性將在未來被移除。
包含 "deprecated" 且值為 true 的根 Schema 表示所描述的整個資源**可能**在未來被移除。
"deprecated" 關鍵字適用於包含該關鍵字的 Schema 物件成功應用的每個實例位置。這可能會導致每個陣列項目或物件屬性都被棄用的情況，即使包含的陣列或物件沒有被棄用。
省略此關鍵字的行為與值為 false 時相同。
這些關鍵字的值**必須**是布林值。當這些關鍵字的多個出現適用於單個子實例時，如果任何出現指定了 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 腳本媒體類型的安全考量。
| [ecma262] | "ECMA-262, 第 11 版規範"，2020 年 6 月。 |
| [json-schema] | Wright, A.、Andrews, H.、Hutton, B. 和 G. Dennis，「JSON Schema：用於描述 JSON 文件的媒體類型」，Internet-Draft draft-bhutton-json-schema-00，2020 年 12 月。 |
| [relative-json-pointer] | Luff, G., Andrews, H. 和 B. Hutton, "相對 JSON 指標", Internet-Draft draft-handrews-relative-json-pointer-01, 2020 年 12 月。 |
| [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 月。 |
| [RFC5321] | Klensin, J., "簡單郵件傳輸協定", RFC 5321, DOI 10.17487/RFC5321, 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 Schema 初始草案所做的貢獻。
感謝 Jason Desrosiers、Daniel Perrett、Erik Wilde、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch、Dave Finlay、Denis Laxalde、Phil Sturgeon、Shawn Silverman 和 Karen Etheridge 對文件提交的內容和修補程式。