インターネットドラフト JSON Schema 検証 2022年6月
Wright ほか 2022年12月18日失効 [ページ]
作業部会:
Internet Engineering Task Force
インターネットドラフト:
draft-bhutton-json-schema-validation-01
公開日:
想定ステータス:
情報提供
失効日:
著者:
A. Wright, 編
H. Andrews, 編
B. Hutton, 編
Postman

JSON Schema 検証：JSON の構造検証のための語彙

概要

JSON Schema（application/schema+json）にはいくつかの目的があり、そのうちの1つは JSON インスタンスの検証です。 この文書は、JSON 文書の意味を記述し、JSON データを扱うユーザーインターフェイスにヒントを提供し、 有効な文書がどのようなものでなければならないかについて表明するための、JSON Schema の語彙を規定します。

読者への注記

このドラフトの課題リストは、 https://github.com/json-schema-org/json-schema-spec/issues にあります。

追加情報については、https://json-schema.org/ を参照してください。

フィードバックを提供するには、この課題追跡システム、ホームページに記載されている連絡方法、 または文書編集者へのメールを使用してください。

このメモの位置付け

このインターネットドラフトは、BCP 78 および BCP 79 の規定に 完全に適合して提出されています。

インターネットドラフトは、Internet Engineering Task Force（IETF）の作業文書です。他のグループも作業文書を インターネットドラフトとして配布する場合があることに注意してください。現在の インターネットドラフトの一覧は https://datatracker.ietf.org/drafts/current/ にあります。

インターネットドラフトは最大6か月間有効なドラフト文書であり、 いつでも他の文書によって更新、置換、または廃止される可能性があります。 インターネットドラフトを参考資料として使用したり、「進行中の作業」として以外に 引用したりすることは適切ではありません。

このインターネットドラフトは2022年12月18日に失効します。

▲

目次

1. はじめに

JSON Schema は、与えられた JSON 文書（インスタンス）が 一定数の基準を満たすことを要求するために使用できます。これらの基準は、 この仕様で説明されるキーワードを使用して表明されます。さらに、対話型 ユーザーインターフェイスでのインスタンス生成を支援するための キーワード群も定義されています。

この仕様は、JSON Schema コア [json-schema] 仕様で定義されている概念、構文、および用語を使用します。

2. 規約と用語

この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、 "SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、 RFC 2119 [RFC2119] で説明されるとおりに解釈されるものとします。

この仕様では、配列インスタンスとオブジェクトインスタンスの両方を指すために "container instance" という用語を使用します。また、配列要素または オブジェクトメンバー値を指すために "children instances" という用語を使用します。

配列値内の要素は、この配列のどの2つの要素も 等しく [json-schema]ない場合、一意であるといいます。

3. 概要

JSON Schema 検証は、インスタンスデータの構造に制約を表明します。 表明されたすべての制約を満たすインスタンス位置には、 記述的メタデータや使用上のヒントなど、非表明情報を含む キーワードによって注釈が付けられます。インスタンス内のすべての位置が 表明されたすべての制約を満たす場合、そのインスタンスは そのスキーマに対して妥当であるといいます。

各スキーマオブジェクトは、それが適用される各インスタンス位置に対して 独立して評価されます。これにより、検証器が文書全体にわたる 検証プロセスの間に状態を維持する必要がないことが保証され、 実装要件が大幅に簡素化されます。

この仕様は、一連の表明キーワードに加えて、JSON インスタンスに 有用な情報を注釈付けするために使用できる小さなメタデータキーワードの語彙を 定義します。Section 7 のキーワードは主に 注釈として意図されていますが、任意で表明として使用することもできます。 Section 8 のキーワードは、JSON 文字列として 埋め込まれた文書を扱うための注釈です。

4. 相互運用性に関する考慮事項

4.1. 文字列 インスタンスの検証

nul 文字（\u0000）は JSON 文字列内で有効であることに注意すべきです。 検証対象のインスタンスは、基盤となるプログラミング言語がそのようなデータを 扱えるかどうかにかかわらず、この文字を含む文字列値を含む場合があります。

4.2. 数値 インスタンスの検証

JSON 仕様は任意精度の数値を許容しており、JSON Schema は そのような境界を追加しません。 これは、JSON Schema によって処理される数値インスタンスが、基盤となる プログラミング言語がそのようなデータを扱えるかどうかにかかわらず、 任意に大きく、かつ/または任意に長い小数部を持てることを意味します。

4.3. 正規表現

正規表現を使用する、またはインスタンス値を正規表現に制約するキーワードは、 JSON Schema Core [json-schema] 仕様における正規表現の 相互運用性に関する考慮事項の対象となります。

5. メタスキーマ

デフォルトの JSON Schema 方言メタスキーマの現在の URI は https://json-schema.org/draft/2020-12/schema です。 スキーマ作成者の便宜のため、このメタスキーマは、この仕様および JSON Schema Core 仕様で定義されるすべての語彙と、 移行期間のために予約されている2つの旧キーワードからなる方言を 記述しています。個々の語彙および語彙メタスキーマの URI は、 以下の各セクションで示されます。一部の語彙はサポートが任意であり、 これは関連するセクションで詳しく説明されています。

エラーを修正するために、仕様ドラフト間で更新された語彙および メタスキーマ URI が公開されることがあります。実装は、 この仕様ドラフトより後で次のドラフトより前の日付を持つ URI を、 ここに列挙されているものと同じ構文および意味論を示すものとして 扱うべきです。

6. 構造検証のための語彙

スキーマ内の検証キーワードは、インスタンスの検証を成功させるための 要件を課します。これらのキーワードはすべて表明であり、注釈動作はありません。

"$vocabulary" を使用しないメタスキーマは、その URI が true の値で 存在するかのように、この語彙を要求するものとして扱うべきです。

Validation 語彙として知られる、この語彙の現在の URI は次のとおりです: <https://json-schema.org/draft/2020-12/vocab/validation>。

対応するメタスキーマの現在の URI は次のとおりです: https://json-schema.org/draft/2020-12/meta/validation。

6.1. 任意のインスタンス型に対する 検証キーワード

6.1.1. type

このキーワードの値は、文字列または配列のいずれかでなければなりません。 配列である場合、その配列の要素は文字列であり、かつ一意でなければなりません。

文字列値は、6つのプリミティブ型 （"null"、"boolean"、"object"、"array"、"number"、または "string"）、 あるいは小数部がゼロの任意の数値に一致する "integer" のいずれかで なければなりません。

"type" の値が文字列である場合、インスタンスの型が その文字列の値によって表される型に一致すれば、検証は成功します。 "type" の値が配列である場合、インスタンスの型が 配列内の文字列によって示される型のいずれかに一致すれば、 検証は成功します。

6.1.2. enum

このキーワードの値は配列でなければなりません。この配列は 少なくとも1つの要素を持つべきです。配列内の要素は一意であるべきです。

インスタンスの値がこのキーワードの配列値内のいずれかの要素と 等しい場合、このキーワードに対する検証は成功します。

配列内の要素は、null を含む任意の型である可能性があります。

6.1.3. const

このキーワードの値は、null を含む任意の型であってもかまいません。

このキーワードの使用は、単一の値を持つ "enum"（Section 6.1.2）と機能的に同等です。

インスタンスの値がこのキーワードの値と等しい場合、 このキーワードに対する検証は成功します。

6.2. 数値インスタンス （number および integer）に対する検証キーワード

6.2.1. multipleOf

"multipleOf" の値は、0より厳密に大きい数値でなければなりません。

数値インスタンスは、このキーワードの値で割った結果が 整数になる場合にのみ妥当です。

6.2.2. maximum

"maximum" の値は、数値インスタンスの包括的な上限を表す 数値でなければなりません。

インスタンスが数値である場合、このキーワードは、インスタンスが "maximum" より小さいか、正確に等しい場合にのみ検証されます。

6.2.3. exclusiveMaximum

"exclusiveMaximum" の値は、数値インスタンスの排他的な上限を表す 数値でなければなりません。

インスタンスが数値である場合、その値が "exclusiveMaximum" より 厳密に小さい（等しくない）場合にのみ、そのインスタンスは妥当です。

6.2.4. minimum

"minimum" の値は、数値インスタンスの包括的な下限を表す 数値でなければなりません。

インスタンスが数値である場合、このキーワードは、インスタンスが "minimum" より大きいか、正確に等しい場合にのみ検証されます。

6.2.5. exclusiveMinimum

"exclusiveMinimum" の値は、数値インスタンスの排他的な下限を表す 数値でなければなりません。

インスタンスが数値である場合、その値が "exclusiveMinimum" より 厳密に大きい（等しくない）場合にのみ、そのインスタンスは妥当です。

6.3. 文字列に対する 検証キーワード

6.3.1. maxLength

このキーワードの値は、非負整数でなければなりません。

文字列インスタンスは、その長さがこのキーワードの値以下である場合、 このキーワードに対して妥当です。

文字列インスタンスの長さは、RFC 8259 [RFC8259] によって定義される文字数として定義されます。

6.3.2. minLength

このキーワードの値は、非負整数でなければなりません。

文字列インスタンスは、その長さがこのキーワードの値以上である場合、 このキーワードに対して妥当です。

文字列インスタンスの長さは、RFC 8259 [RFC8259] によって定義される文字数として定義されます。

このキーワードを省略することは、値 0 と同じ動作をします。

6.3.3. pattern

このキーワードの値は文字列でなければなりません。この文字列は、 ECMA-262 正規表現方言に従った有効な正規表現であるべきです。

正規表現がインスタンスに正常に一致する場合、文字列インスタンスは 妥当であるとみなされます。注意: 正規表現は暗黙的にアンカーされません。

6.4. 配列に対する 検証キーワード

6.4.1. maxItems

このキーワードの値は、非負整数でなければなりません。

配列インスタンスは、そのサイズがこのキーワードの値以下である場合、 "maxItems" に対して妥当です。

6.4.2. minItems

このキーワードの値は、非負整数でなければなりません。

配列インスタンスは、そのサイズがこのキーワードの値以上である場合、 "minItems" に対して妥当です。

このキーワードを省略することは、値 0 と同じ動作をします。

6.4.3. uniqueItems

このキーワードの値は boolean でなければなりません。

このキーワードの boolean 値が false の場合、インスタンスは 正常に検証されます。boolean 値が true の場合、そのすべての要素が 一意であれば、インスタンスは正常に検証されます。

このキーワードを省略することは、値 false と同じ動作をします。

6.4.4. maxContains

このキーワードの値は、非負整数でなければなりません。

"contains" が同じスキーマオブジェクト内に存在しない場合、 このキーワードは効果を持ちません。

インスタンス配列は、隣接する "contains" [json-schema] キーワードの注釈結果の形式に応じて、 2つの方法で "maxContains" に対して妥当になります。1つ目は、 注釈結果が配列であり、その配列の長さが "maxContains" の値以下である場合です。 2つ目は、注釈結果が boolean "true" であり、インスタンス配列の長さが "maxContains" の値以下である場合です。

6.4.5. minContains

このキーワードの値は、非負整数でなければなりません。

"contains" が同じスキーマオブジェクト内に存在しない場合、 このキーワードは効果を持ちません。

インスタンス配列は、隣接する "contains" [json-schema] キーワードの注釈結果の形式に応じて、 2つの方法で "minContains" に対して妥当になります。1つ目は、 注釈結果が配列であり、その配列の長さが "minContains" の値以上である場合です。 2つ目は、注釈結果が boolean "true" であり、インスタンス配列の長さが "minContains" の値以上である場合です。

値 0 は許可されますが、0 から "maxContains" の値までの 出現範囲を設定する場合にのみ有用です。値 0 は "minContains" と "contains" が常に検証に合格する原因となります （ただし、"maxContains" キーワードに対する検証は失敗する可能性があります）。

このキーワードを省略することは、値 1 と同じ動作をします。

6.5. オブジェクトに対する 検証キーワード

6.5.1. maxProperties

このキーワードの値は、非負整数でなければなりません。

オブジェクトインスタンスは、そのプロパティ数がこのキーワードの値以下である場合、 "maxProperties" に対して妥当です。

6.5.2. minProperties

このキーワードの値は、非負整数でなければなりません。

オブジェクトインスタンスは、そのプロパティ数がこのキーワードの値以上である場合、 "minProperties" に対して妥当です。

このキーワードを省略することは、空の配列と同じ動作をします。

6.5.3. required

このキーワードの値は配列でなければなりません。 この配列の要素がある場合、それらは文字列であり、かつ一意でなければなりません。

配列内のすべての項目がインスタンス内のプロパティ名である場合、 オブジェクトインスタンスはこのキーワードに対して妥当です。

このキーワードを省略することは、空の配列と同じ動作をします。

6.5.4. dependentRequired

このキーワードの値はオブジェクトでなければなりません。このオブジェクト内の プロパティがある場合、それらは配列でなければなりません。各配列内の 要素がある場合、それらは文字列であり、かつ一意でなければなりません。

このキーワードは、特定の他のプロパティが存在する場合に 必須となるプロパティを指定します。それらの要件は、 他のプロパティの存在に依存します。

インスタンス内とこのキーワードの値内の名前としての両方に現れる 各名前について、対応する配列内のすべての項目も インスタンス内のプロパティ名である場合、検証は成功します。

このキーワードを省略することは、空のオブジェクトと同じ動作をします。

7. "format" を用いるセマンティックコンテンツのための語彙

7.1. 前書き

構造検証だけでは、アプリケーションが特定の値を正しく利用できるようにするには 不十分な場合があります。"format" 注釈キーワードは、RFC やその他の外部仕様などの 権威あるリソースによって正確に記述される、固定された値の部分集合について、 スキーマ作成者がセマンティック情報を伝達できるように定義されています。

このキーワードの値は format 属性と呼ばれます。これは文字列でなければなりません。 format 属性は一般に、与えられたインスタンス型の集合のみを検証できます。 検証対象のインスタンスの型がこの集合に含まれない場合、この format 属性およびインスタンスに対する検証は成功すべきです。このセクションで 定義されるすべての format 属性は文字列に適用されますが、format 属性は、 コア JSON Schema [json-schema] で定義されるデータモデル内の任意のインスタンス型に適用されるように 指定できます。 この仕様の "type" キーワードは、データモデルの一部ではない "integer" 型を定義していることに注意してください。したがって、format 属性は 数値に限定できますが、整数に具体的に限定することはできません。ただし、 数値 format は値 "integer" を持つ "type" キーワードと併用できます。 あるいは、数値が整数でない場合に常に合格するよう明示的に定義することもでき、 これは本質的に整数にのみ適用する場合と同じ動作を生み出します。

Format-Annotation 語彙として知られる、この語彙の現在の URI は次のとおりです: <https://json-schema.org/draft/2020-12/vocab/format-annotation>。対応する メタスキーマの現在の URI は次のとおりです: https://json-schema.org/draft/2020-12/meta/format-annotation。 この語彙のサポートを実装することは必須です。

Format-Annotation 語彙に加えて、カスタムメタスキーマ向けに "format" を表明として定義する二次的な語彙を利用できます。 Format-Assertion 語彙の URI は次のとおりです: <https://json-schema.org/draft/2020-12/vocab/format-assertion>。対応する メタスキーマの現在の URI は次のとおりです: https://json-schema.org/draft/2020-12/meta/format-assertion。 Format-Assertion 語彙のサポートを実装することは任意です。

Format-Annotation 語彙と Format-Assertion 語彙の両方を指定することは、 要件が Format-Annotation 語彙のスーパーセットであるため、 Format-Assertion 語彙のみを指定することと機能的に同等です。

7.2. 実装 要件

"format" キーワードは、参照される語彙によって定義されるとおりに機能します。

7.2.1. Format-Annotation 語彙

実装が注釈収集をサポートする場合、format の値は注釈として 収集されなければなりません。これにより、スキーマ検証が利用できない場合や 不十分な場合に、アプリケーションレベルの検証が可能になります。

実装は、注釈に加えて "format" を表明として扱い、指定された 意味論への値の適合性を検証しようとしてもかまいません。実装は、 そのような評価を有効化および無効化するオプションを提供しなければならず、 デフォルトでは無効でなければなりません。実装は、そのような検証に対する サポートレベルを文書化すべきです。 Format-Annotation 語彙を指定して実装で検証を有効化することは、 Format-Assertion 語彙を指定することと同等とみなすべきではありません。 Format-Assertion 語彙が指定されていない場合、実装は完全な検証サポートを 提供することを要求されないためです。

実装が表明動作に設定されている場合、それは次のことを行います:

  • 以下で定義される各 format 属性について、実装固有のベストエフォート検証を 提供すべきです。
  • 任意またはすべての format 属性の検証を、常に true の検証結果を生成する no-op として実装することを選択してもかまいません。

これは、現在の実装の実態、すなわち一部またはすべての format 属性について、 検証なしを含む大きく異なる検証レベルを提供している現状に一致します。 また、注釈動作のみに依存し、推奨されるベストプラクティスである アプリケーション内でのセマンティック検証を促進するよう設計されています。

7.2.2. Format-Assertion 語彙

Format-Assertion 語彙が true の値で宣言されている場合、 実装はこの仕様で定義されるすべての format に対して完全な検証サポートを 提供しなければなりません。完全な検証サポートを提供できない実装は、 そのスキーマの処理を拒否しなければなりません。

Format-Assertion 語彙をサポートする実装は次のことを行います:

  • 実装が注釈収集をサポートする場合、引き続き "format" を注釈として 収集しなければなりません。
  • "format" を表明として評価しなければなりません。
  • この仕様で定義されるすべての format 属性、および認識する追加の format 属性について、正しい型のインスタンス値であっても検証に 失敗する可能性が存在するような構文的検証を実装しなければなりません。

format 属性の最小限の検証に関する要件は、多くの属性に伴う複雑さのため、 意図的に曖昧かつ許容的です。特に、この要件は構文的チェックに限定されることに 注意してください。実装がメールを送信したり、URL への接続を試みたり、 format インスタンスによって識別されるエンティティの存在を他の方法で 確認したりすることは期待されません。 期待されるのは、date-time のような単純な format については構文的検証が 徹底されることです。email addresses のような複雑な format については、 それがさまざまな標準と長年にわたる多数の調整を合わせたものであり、 値を使用する他のアプリケーションによって制限される場合もされない場合もある 不明瞭または廃止された規則を含むため、最小限の検証で十分です。 たとえば、"@" を含まないインスタンス文字列は明らかに有効な メールアドレスではなく、7ビット ASCII の範囲外の文字を含む "email" または "hostname" も同様に明らかに無効です。

実装は、各 format に共通の解析ライブラリ、またはよく知られた正規表現を 使用することが推奨されます。実装は、各 format 属性がどのように、 どの程度検証されるかを明確に文書化すべきです。

標準のコアおよび検証メタスキーマ（Section 5） は、この語彙を "$vocabulary" キーワード内に false の値で含めています。 これは、デフォルトでは実装がこのキーワードを表明としてサポートすることを 要求されないためです。format 語彙を true の値でサポートすることは、 コードサイズを大幅に増加させ、場合によっては実行時間も増加させると理解されており、 すべての実装に適しているわけではありません。

7.2.3. カスタム format 属性

実装はカスタム format 属性をサポートしてもかまいません。当事者間の合意がない限り、 スキーマ作成者は、相手方の実装がそのようなカスタム format 属性をサポートすることを 期待してはなりません。実装は、未知の format を注釈として収集することに 失敗してはなりません。Format-Assertion 語彙が指定されている場合、 実装は未知の format に遭遇した時点で失敗しなければなりません。

語彙は、キーワードに対して異なる値集合を具体的に宣言することをサポートしません。 この制限と、このキーワードの歴史的に不均一な実装のため、 相互運用性が望まれる場合には、追加の format 属性ではなく、 カスタム語彙内に追加のキーワードを定義することが推奨されます。

7.3. 定義済みフォーマット

7.3.1. 日付、時刻、および 期間

これらの属性は文字列インスタンスに適用されます。

日付および時刻の format 名は、 RFC 3339, section 5.6 [RFC3339] に由来します。 duration format は、RFC 3339 の Appendix A に示されている ISO 8601 ABNF に由来します。

format をサポートする実装は、次の属性のサポートを 実装すべきです。

date-time:
文字列インスタンスは、（上記で参照される） "date-time" ABNF 規則に従った有効な表現である場合、 この属性に対して妥当です。
date:
文字列インスタンスは、（上記で参照される） "full-date" ABNF 規則に従った有効な表現である場合、 この属性に対して妥当です。
time:
文字列インスタンスは、（上記で参照される） "full-time" ABNF 規則に従った有効な表現である場合、 この属性に対して妥当です。
duration:
文字列インスタンスは、（上記で参照される） "duration" ABNF 規則に従った有効な表現である場合、 この属性に対して妥当です。

実装は、その RFC 内の任意の場所で定義されている他の format 名を使用して追加の属性をサポートしてもかまいません。 "full-date" または "full-time" が実装されている場合、 対応する短い形式（それぞれ "date" または "time"）も 実装されなければならず、同一に動作しなければなりません。 実装は、その format の規則に従って検証しない限り、 RFC 3339 format に一致する名前を持つ拡張属性を 定義すべきではありません。 現在、すべての RFC 3339 format をサポートする必要性について 合意はありません。そのため、このように名前空間を予約する方式は、 全体の集合にコミットすることなく実験を促進します。 format 実装要件は一般により柔軟になるか、これらは最終的に 完全に指定された属性に昇格するか、削除される可能性があります。

7.3.2. メールアドレス

これらの属性は文字列インスタンスに適用されます。

文字列インスタンスは、次のような有効なインターネットメールアドレスである場合、 これらの属性に対して妥当です。

email:
RFC 5321, section 4.1.2 [RFC5321] の "Mailbox" ABNF 規則によって 定義されるとおりです。
idn-email:
RFC 6531, section 3.3 [RFC6531] の拡張 "Mailbox" ABNF 規則によって 定義されるとおりです。

"email" 属性に対して有効なすべての文字列は、 "idn-email" 属性に対しても有効であることに注意してください。

7.3.3. ホスト名

これらの属性は文字列インスタンスに適用されます。

文字列インスタンスは、次のようなインターネットホスト名の有効な表現である場合、 これらの属性に対して妥当です。

hostname:
RFC 1123, section 2.1 [RFC1123] によって定義されるとおりであり、 RFC 5891, section 4.4 [RFC5891] で指定される Punycode アルゴリズムを 使用して生成されたホスト名を含みます。
idn-hostname:
hostname と同様に RFC 1123 によって定義されるもの、または RFC 5890, section 2.3.2.3 [RFC5890] によって定義される国際化ホスト名の いずれかです。

"hostname" 属性に対して有効なすべての文字列は、 "idn-hostname" 属性に対しても有効であることに注意してください。

7.3.4. IP アドレス

これらの属性は文字列インスタンスに適用されます。

文字列インスタンスは、次のような IP アドレスの有効な表現である場合、 これらの属性に対して妥当です。

ipv4:
RFC 2673, section 3.2 [RFC2673] で定義される "dotted-quad" ABNF 構文に従う IPv4 アドレスです。
ipv6:
RFC 4291, section 2.2 [RFC4291] で定義される IPv6 アドレスです。

7.3.5. リソース識別子

これらの属性は文字列インスタンスに適用されます。

uri:
文字列インスタンスは、[RFC3986] に従う 有効な URI である場合、この属性に対して妥当です。
uri-reference:
文字列インスタンスは、[RFC3986] に従う 有効な URI Reference（URI または relative-reference のいずれか）である場合、 この属性に対して妥当です。
iri:
文字列インスタンスは、[RFC3987] に従う 有効な IRI である場合、この属性に対して妥当です。
iri-reference:
文字列インスタンスは、[RFC3987] に従う 有効な IRI Reference（IRI または relative-reference のいずれか）である場合、 この属性に対して妥当です。
uuid:
文字列インスタンスは、[RFC4122] に従う UUID の有効な 文字列表現である場合、この属性に対して妥当です。

すべての有効な URI は有効な IRI であり、すべての有効な URI References も 有効な IRI References であることに注意してください。

また、"uuid" format はプレーンな UUID のためのものであり、URN 内の UUID のための ものではないことにも注意してください。例は "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" です。 URN としての UUID には、URI スキームおよび URN 名前空間を示すために "^urn:uuid:" の "pattern" 正規表現とともに、"uri" format を使用してください。

7.3.6. uri-template

この属性は文字列インスタンスに適用されます。

文字列インスタンスは、[RFC6570] に従う 有効な URI Template（任意のレベル）である場合、この属性に対して妥当です。

URI Templates は IRI に使用できることに注意してください。別個の IRI Template 仕様はありません。

7.3.7. JSON ポインター

これらの属性は文字列インスタンスに適用されます。

json-pointer:
文字列インスタンスは、 RFC 6901, section 5 [RFC6901] に従う JSON Pointer の有効な JSON 文字列表現である場合、 この属性に対して妥当です。
relative-json-pointer:
文字列インスタンスは、有効な Relative JSON Pointer [relative-json-pointer] である場合、 この属性に対して妥当です。

絶対および相対 JSON Pointers の両方を許可するには、 "anyOf" または "oneOf" を使用して、いずれかの format のサポートを示してください。

7.3.8. regex

この属性は文字列インスタンスに適用されます。

正規表現であり、 ECMA-262 [ecma262] 正規表現方言に従って有効であるべきです。

format を検証する実装は、この仕様の 正規表現（Section 4.3） セクションで定義された ECMA-262 の少なくとも部分集合を受け入れなければならず、 すべての有効な ECMA-262 表現を受け入れるべきです。

8. 文字列エンコードされたデータの内容のための語彙

8.1. 前書き

このセクションで定義される注釈は、インスタンスが JSON 文字列にエンコードされた非 JSON データを含むことを示します。

これらのプロパティは、JSON データをリッチなマルチメディア文書として 解釈するために必要な追加情報を提供します。これらは、内容の種類、 それがどのようにエンコードされているか、かつ/またはどのように検証できるかを 記述します。これらは検証表明としては機能しません。 不正な形式の文字列エンコード文書によって、それを含むインスタンスが 無効とみなされてはなりません。

"$vocabulary" を使用しないメタスキーマは、その URI が true の値で 存在するかのように、この語彙を要求するものとして扱うべきです。

Content 語彙として知られる、この語彙の現在の URI は次のとおりです: <https://json-schema.org/draft/2020-12/vocab/content>。

対応するメタスキーマの現在の URI は次のとおりです: https://json-schema.org/draft/2020-12/meta/content。

8.2. 実装 要件

セキュリティおよび性能上の懸念、ならびに可能な内容型が オープンエンドであることから、実装は、デフォルトで文字列の内容を 自動的にデコード、解析、かつ/または検証してはなりません。これはさらに、 埋め込まれた文書が、それを含む文書を処理したものとは異なる コンシューマによって処理されることを意図したユースケースもサポートします。

このセクションのすべてのキーワードは文字列にのみ適用され、他の データ型には効果を持ちません。

実装は、文字列の内容を自動的にデコード、解析、かつ/または検証する 機能を提供してもかまいません。ただし、これらの操作をデフォルトで 実行してはならず、各文字列エンコード文書の検証結果を、 それを囲む文書とは別に提供しなければなりません。この処理は、 元のスキーマに対してインスタンスを完全に評価し、その後、注釈を使用して 各文字列エンコード文書をデコード、解析、かつ/または検証することと 同等であるべきです。 現時点では、そのような自動デコード、解析、検証機能から 解析済みデータかつ/または検証結果を実行して返す正確な仕組みは 未規定のままです。そのような機能が普及した場合、将来のドラフトで より詳細に規定される可能性があります。

これらのキーワードに従ってインスタンス文字列を自動処理することで 導入される可能性のある脆弱性については、 セキュリティに関する考慮事項（Section 10） のセクションも参照してください。

8.3. contentEncoding

インスタンス値が文字列である場合、このプロパティは、その文字列が エンコードされたバイナリデータとして解釈され、このプロパティで指定された エンコーディングを使用してデコードされるべきであることを定義します。

base 16、32、および 64 のエンコーディングを示す可能な値と いくつかのバリエーションは、RFC 4648 [RFC4648] に列挙されています。さらに、 RFC 2045 [RFC2045] の 6.7 節および 6.8 節は、 MIME で使用されるエンコーディングを提供します。このキーワードは、 バイナリデータを ASCII 文字にマップするために設計された MIME の Content-Transfer-Encoding ヘッダーに由来します。これは、 HTTP リクエストおよびレスポンスの内容をエンコードする （例: 圧縮または暗号化する）ために使用される HTTP の Content-Encoding ヘッダーとは関係ありません。

"base64" は両方の RFC で定義されているため、その文字列が MIME コンテキストでの使用を明確に意図している場合を除き、 RFC 4648 の定義が想定されるべきです。これらのエンコーディングはすべて、 7ビット ASCII 文字のみからなる文字列になることに注意してください。 したがって、このキーワードは、その範囲外の文字を含む文字列には 意味を持ちません。

このキーワードが存在しないが "contentMediaType" が存在する場合、これは エンコーディングが identity エンコーディングであること、つまり UTF-8 文字列で内容を表すために変換が不要であったことを示します。

このプロパティの値は文字列でなければなりません。

8.4. contentMediaType

インスタンスが文字列である場合、このプロパティはその文字列の内容の メディアタイプを示します。"contentEncoding" が存在する場合、 このプロパティはデコードされた文字列を記述します。

このプロパティの値は文字列でなければならず、かつ RFC 2046 [RFC2046] で定義されるメディアタイプで なければなりません。

8.5. contentSchema

インスタンスが文字列であり、かつ "contentMediaType" が存在する場合、この プロパティはその文字列の構造を記述するスキーマを含みます。

このキーワードは、JSON Schema のデータモデルにマップできる任意の メディアタイプとともに使用してもかまいません。

このプロパティの値は有効な JSON スキーマでなければなりません。 "contentMediaType" が存在しない場合は無視されるべきです。

8.6. 例

これは、"contentEncoding" と "contentMediaType" の使用を示すスキーマ例です:


{
    "type": "string",
    "contentEncoding": "base64",
    "contentMediaType": "image/png"
}

このスキーマによって記述されるインスタンスは文字列であることが期待され、 その値は base64 エンコードされた PNG 画像として解釈できるべきです。

別の例です:


{
    "type": "string",
    "contentMediaType": "text/html"
}

このスキーマによって記述されるインスタンスは、HTML を含む文字列であることが 期待され、JSON 文字列がデコードされた文字セットを使用します。 RFC 8259 [RFC8259] の 8.1 節に従い、完全に閉じた システムの外では、これは UTF-8 でなければなりません。

この例は、HMAC SHA-256 アルゴリズムを使用して MAC された JWT を記述し、 その claim set 内の "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 文字列を 2つの JSON データ構造のリスト、すなわち最初にヘッダー、次にペイロードへと どのようにデコードするかを決定します。JWT メディアタイプは JWT が JSON 文字列で表現できることを保証するため、それ以上のエンコードまたは デコードは不要です。

9. 基本メタデータ注釈のための語彙

これらの汎用注釈キーワードは、文書化およびユーザーインターフェイスでの 表示目的で一般的に使用される情報を提供します。これらは包括的な 機能集合を形成することを意図していません。むしろ、より複雑な 注釈ベースのアプリケーションのために追加の語彙を定義できます。

"$vocabulary" を使用しないメタスキーマは、その URI が true の値で 存在するかのように、この語彙を要求するものとして扱うべきです。

Meta-Data 語彙として知られる、この語彙の現在の URI は次のとおりです: <https://json-schema.org/draft/2020-12/vocab/meta-data>。

対応するメタスキーマの現在の URI は次のとおりです: https://json-schema.org/draft/2020-12/meta/meta-data。

9.1. "title" と "description"

これら両方のキーワードの値は文字列でなければなりません。

これら両方のキーワードは、このユーザーインターフェイスによって生成される データに関する情報でユーザーインターフェイスを装飾するために使用できます。 title は短いことが望ましく、description はこのスキーマによって記述される インスタンスの目的について説明を提供します。

9.2. "default"

このキーワードの値には制限はありません。このキーワードの複数の出現が 単一のサブインスタンスに適用可能な場合、実装は重複を削除すべきです。

このキーワードは、特定のスキーマに関連付けられたデフォルトの JSON 値を 提供するために使用できます。デフォルト値は、関連付けられたスキーマに対して 妥当であることが推奨されます。

9.3. "deprecated"

このキーワードの値は boolean でなければなりません。このキーワードの複数の出現が 単一のサブインスタンスに適用可能な場合、いずれかの出現が true 値を指定していれば、 アプリケーションはそのインスタンス位置を非推奨とみなすべきです。

"deprecated" が boolean true の値を持つ場合、それはアプリケーションが 宣言されたプロパティの使用を控えるべきであることを示します。これは、 そのプロパティが将来削除される可能性があることを意味してもかまいません。

true の値を持つ "deprecated" を含むルートスキーマは、記述されている リソース全体が将来削除される可能性があることを示します。

"deprecated" キーワードは、そのキーワードを含むスキーマオブジェクトが 正常に適用される各インスタンス位置に適用されます。これにより、 それを含む配列またはオブジェクトは非推奨でないにもかかわらず、 すべての配列項目またはオブジェクトプロパティが非推奨となる シナリオが生じる可能性があります。

このキーワードを省略することは、値 false と同じ動作をします。

9.4. "readOnly" と "writeOnly"

これらのキーワードの値は boolean でなければなりません。これらのキーワードの 複数の出現が単一のサブインスタンスに適用可能な場合、いずれかの出現が true 値を指定していれば、結果の動作は true 値の場合と同様であるべきであり、 それ以外の場合は false 値の場合と同様であるべきです。

"readOnly" が boolean true の値を持つ場合、それはインスタンスの値が 所有権限者によって排他的に管理されており、このプロパティの値を変更しようとする アプリケーションの試みは、その所有権限者によって無視または拒否されることが 期待されることを示します。

文書全体について "readOnly" とマークされたインスタンス文書は、 所有権限者に送信された場合、所有権限者の裁量で無視されてもよく、 またはエラーとなってもかまいません。

"writeOnly" が boolean true の値を持つ場合、それは所有権限者から インスタンスが取得されるときに、その値が決して存在しないことを示します。 文書（またはそれが表すリソース）を更新または作成するために所有権限者へ 送信されるときには存在してもかまいませんが、更新された、または新しく作成された インスタンスのいかなるバージョンにも含まれません。

文書全体について "writeOnly" とマークされたインスタンス文書は、 何らかの空白文書として返されてもよく、取得時にエラーを生成してもよく、 または所有権限者の裁量で取得リクエストが無視されてもかまいません。

たとえば、"readOnly" はデータベースで生成されたシリアル番号を 読み取り専用としてマークするために使用され、"writeOnly" はパスワード 入力フィールドをマークするために使用されます。

これらのキーワードは、ユーザーインターフェイスでのインスタンス生成を支援するために 使用できます。特に、アプリケーションは write-only フィールドについて、 入力値が入力されるときにそれを隠すウィジェットを使用することを 選択してもかまいません。

これらのキーワードを省略することは、値 false と同じ動作をします。

9.5. "examples"

このキーワードの値は配列でなければなりません。 配列内の値には制限はありません。 このキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、 実装は配列の配列ではなく、すべての値からなるフラットな配列を 提供しなければなりません。

このキーワードは、使用法を示す目的で、特定のスキーマに関連付けられた サンプル JSON 値を提供するために使用できます。これらの値は、 関連付けられたスキーマに対して妥当であることが推奨されます。

実装は、"default" の値が存在する場合、それを追加の例として 使用してもかまいません。"examples" が存在しない場合でも、"default" は このように使用されてもかまいません。

10. セキュリティに関する考慮事項

JSON Schema 検証は JSON Schema コアのための語彙を定義し、そこに列挙されている すべてのセキュリティに関する考慮事項に関係します。

JSON Schema 検証は正規表現の使用を許可しますが、正規表現には多数の 異なる（しばしば互換性のない）実装があります。 一部の実装は任意のコードの埋め込みを許可しますが、これは JSON Schema の 範囲外であり、許可されてはなりません。 また、正規表現はしばしば計算に極めて高いコストがかかるように作成でき （いわゆる「破滅的バックトラッキング」）、サービス拒否攻撃を 引き起こします。

"contentEncoding" かつ/または "contentMediaType" に基づいて インスタンス文字列データを検証またはその他の方法で評価することをサポートする実装は、 誤解を招く情報に基づいて安全でない方法でデータを評価するリスクがあります。 アプリケーションは、スキーマとインスタンスの間に関係が確立されている場合 （例: それらが同じ権限を共有する場合）にのみそのような処理を実行することで、 このリスクを軽減できます。

メディアタイプまたはエンコーディングの処理は、そのメディアタイプまたは エンコーディングのセキュリティに関する考慮事項の対象となります。たとえば、 JSON 文字列内にエンコードされた JavaScript または ECMAScript を処理する場合、 RFC 4329 Scripting Media Types [RFC4329] のセキュリティに関する考慮事項が適用されます。

11. 参考文献

11.1. 規範的参考文献

[RFC2119]
Bradner, S., "RFC において要求レベルを 示すために用いるキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC1123]
Braden, R., Ed., "インターネット ホストの要件 - アプリケーションとサポート", STD 3, RFC 1123, DOI 10.17487/RFC1123, , <https://www.rfc-editor.org/info/rfc1123>.
[RFC2045]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: インターネット メッセージ本文の形式", RFC 2045, DOI 10.17487/RFC2045, , <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: メディアタイプ", RFC 2046, DOI 10.17487/RFC2046, , <https://www.rfc-editor.org/info/rfc2046>.
[RFC2673]
Crawford, M., "ドメイン ネームシステムにおけるバイナリラベル", RFC 2673, DOI 10.17487/RFC2673, , <https://www.rfc-editor.org/info/rfc2673>.
[RFC3339]
Klyne, G. and C. Newman, "インターネット上の日付と時刻: タイムスタンプ", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): 汎用構文", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC3987]
Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, , <https://www.rfc-editor.org/info/rfc3987>.
[RFC4122]
Leach, P., Mealling, M., and R. Salz, "Universally Unique IDentifier (UUID) URN 名前空間", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/info/rfc4122>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 アドレス指定アーキテクチャ", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC4648]
Josefsson, S., "Base16、Base32、および Base64 データエンコーディング", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
[RFC5321]
Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, , <https://www.rfc-editor.org/info/rfc5321>.
[RFC5890]
Klensin, J., "Internationalized Domain Names for Applications (IDNA): 定義と文書フレームワーク", RFC 5890, DOI 10.17487/RFC5890, , <https://www.rfc-editor.org/info/rfc5890>.
[RFC5891]
Klensin, J., "Internationalized Domain Names in Applications (IDNA): プロトコル", RFC 5891, DOI 10.17487/RFC5891, , <https://www.rfc-editor.org/info/rfc5891>.
[RFC6570]
Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, , <https://www.rfc-editor.org/info/rfc6570>.
[RFC6531]
Yao, J. and W. Mao, "国際化メールのための SMTP 拡張", RFC 6531, DOI 10.17487/RFC6531, , <https://www.rfc-editor.org/info/rfc6531>.
[RFC6901]
Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, , <https://www.rfc-editor.org/info/rfc6901>.
[RFC8259]
Bray, T., Ed., "JavaScript Object Notation (JSON) データ交換形式", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[ecma262]
"ECMA-262, 第11版仕様", , <https://262.ecma-international.org/5.1/>.
[relative-json-pointer]
Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", 進行中の作業, Internet-Draft, draft-handrews-relative-json-pointer-01, , <https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01>.
[json-schema]
Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: JSON 文書を記述するためのメディアタイプ", 進行中の作業, Internet-Draft, draft-bhutton-json-schema-01, , <https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01>.

11.2. 参考情報としての参考文献

[RFC4329]
Hoehrmann, B., "スクリプトメディアタイプ", RFC 4329, DOI 10.17487/RFC4329, , <https://www.rfc-editor.org/info/rfc4329>.

付録 A. Validation から Core に移動されたキーワード

このドラフトの時点で、いくつかのキーワードはこの文書から Core 仕様 [json-schema] へ移動されており、場合によっては 名前変更またはその他の変更を伴います。これは、次の旧 validation キーワードに影響します:

"definitions"
"$ref" に合わせ、また入力を短くするために "$defs" に名前変更されました。 スキーマ語彙の作成者は、旧名をまだ使用しているスキーマを無効化することを 避けるため、異なる動作を持つ "definitions" キーワードを 定義すべきではありません。"definitions" はこの文書で参照される 単一語彙メタスキーマには存在しませんが、デフォルトのメタスキーマには 依然として存在し、実装は、そのメタスキーマが使用される場合、 "$defs" と "definitions" が同じ動作を持つと想定すべきです。
"allOf", "anyOf", "oneOf", "not", "if", "then", "else", "items", "additionalItems", "contains", "propertyNames", "properties", "patternProperties", "additionalProperties"
これらのキーワードはすべて、サブスキーマをインスタンスに適用し、 それらの結果を結合しますが、それ自体ではいかなる条件も表明しません。 表明キーワードがなければ、これらの applicator は false boolean スキーマを 使用するか、true boolean スキーマ（または同等のスキーマオブジェクト）の結果を 反転することによってのみ、表明失敗を引き起こすことができます。 このため、validation、hyper-schema、および拡張語彙がすべて基盤にできる 汎用メカニズムとして定義するほうが適切です。
"dependencies"
このキーワードには2つの異なる動作モードがあり、 実装および推論が比較的困難でした。 スキーマ形式は Core に移動され、applicator 語彙の一部として "dependentSchemas" に名前変更されました。 これは "properties" に類似していますが、サブスキーマを プロパティ値に適用するのではなく、そのプロパティを含むオブジェクトに 適用します。 プロパティ名配列形式はここに保持され、"dependentRequired" に 名前変更されました。これは、"required" 表明キーワードの条件付き使用の 近道である表明であるためです。

付録 B. 謝辞

JSON Schema の初期ドラフトに取り組んだ Gary Court、 Francis Galiegue、 Kris Zyp、 および Geraint Luff に感謝します。

文書への提出およびパッチについて、 Jason Desrosiers、 Daniel Perrett、 Erik Wilde、 Evgeny Poberezkin、 Brad Bowman、 Gowry Sankar、 Donald Pipowitch、 Dave Finlay、 Denis Laxalde、 Phil Sturgeon、 Shawn Silverman、 および Karen Etheridge に感謝します。

付録 C. 変更履歴

このセクションは Internet-Draft ステータスを離れる前に削除されます。

draft-bhutton-json-schema-validation-01
  • "minContains" キーワードの 説明を改善および明確化
  • "production" の使用をやめ、"ABNF rule" を使用
draft-bhutton-json-schema-validation-00
  • email format の RFC 参照を 5322 ではなく 5321 に修正
  • "contentEncoding" 値の集合と意味を明確化
  • 正規表現サポートについて ECMA-262 第11版を参照
  • "format" を注釈専用語彙と 表明語彙に分割
  • 配列に適用される場合の "deprecated" を明確化
draft-handrews-json-schema-validation-02
  • キーワードを正式な語彙に分類
  • "format" 実装要件を語彙の観点で更新
  • デフォルトでは "format" は検証されてはならないが、 検証は有効化できる
  • 語彙宣言を使用して "format" 検証を要求できる
  • "definitions" を "$defs" としてコア仕様へ移動
  • applicator キーワードをコア仕様へ移動
  • "dependencies" の配列形式を "dependentRequired" に名前変更し、スキーマ形式をコア仕様へ移動
  • すべての "content*" キーワードを表明ではなく 注釈として規定
  • 文字列エンコード文書にスキーマを適用できるよう "contentSchema" を追加
  • "contentEncoding" で RFC 4648 エンコーディングも許可
  • "minContains" と "maxContains" を追加
  • "hostname" と "idn-hostname" の RFC 参照を更新
  • "uuid" および "duration" formats を追加
draft-handrews-json-schema-validation-01
  • このドラフトは純粋な明確化であり、機能変更はない
  • "not" および類似のケースで注釈を無視する背後にある 一般原則を提供
  • "if"/"then"/"else" の検証相互作用を明確化
  • 注釈に対する "if"/"then"/"else" の動作を明確化
  • 軽微な書式設定および相互参照の改善
draft-handrews-json-schema-validation-00
  • "if"/"then"/"else" を追加
  • コア仕様に従ってキーワードを表明または注釈として分類
  • 将来的に "dependencies" を削除する可能性について警告
  • 読みやすさのために検証キーワードを サブセクションに分類
  • "readOnly" を hyper-schema から validation meta-data へ移動
  • "writeOnly" を追加
  • 旧 hyper-schema の "media" キーワードを含む 文字列エンコードメディアセクションを追加
  • "regex" format を復元（削除は意図しないものだった）
  • "date" および "time" formats を追加し、追加の RFC 3339 format 名を予約
  • I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email"
  • "json-pointer" format が URI fragment ではなく文字列 エンコーディングを意味することを明確化
  • "minimum" と "exclusiveMinimum" の意味を反転させていた誤字を修正
  • format 構文参照を Normative References へ移動
  • JSON は規範的要件である
draft-wright-json-schema-validation-01
  • 完全な単語を用いたハイフン区切りの format 名に標準化 （"uriref" は "uri-reference" になる）
  • formats "uri-template" および "json-pointer" を追加
  • "exclusiveMaximum"/"exclusiveMinimum" を "maximum"/"minimum" の boolean 修飾子から独立した数値フィールドへ変更
  • additionalItems/items を2つのセクションに分割
  • properties/patternProperties/additionalProperties の定義を 再構成
  • "examples" キーワードを追加
  • "contains" キーワードを追加
  • 空の "required" および "dependencies" 配列を許可
  • "type" のプリミティブ型への参照を修正
  • "const" キーワードを追加
  • "propertyNames" キーワードを追加
draft-wright-json-schema-validation-00
  • 追加のセキュリティに関する考慮事項を追加
  • "latest version" メタスキーマへの参照を削除し、 番号付きバージョンを使用
  • 簡潔さのため多くのキーワード定義を言い換え
  • 相対 URI 参照も許可する "uriref" format を追加
draft-fge-json-schema-validation-00
  • 初期ドラフト。
  • draft v3 から救済。
  • "required" キーワードを再定義。
  • "extends"、"disallow" を削除
  • "anyOf"、"allOf"、"oneOf"、"not"、"definitions"、 "minProperties"、 "maxProperties" を追加。
  • "dependencies" メンバー値は単一の 文字列ではなくなった。プロパティ依存配列には 少なくとも1つの要素が必要。
  • "divisibleBy" を "multipleOf" に名前変更。
  • "type" 配列はスキーマを持てなくなった。"any" を可能な 値として削除。
  • "format" セクションを再構成し、サポートを任意にする。
  • "format": 属性 "phone"、"style"、"color" を削除。 "ip-address" を "ipv4" に名前変更。すべての属性に参照を追加。
  • 配列/オブジェクト インスタンスのスキーマを計算するアルゴリズムを提供。
  • 相互運用性に関する考慮事項を追加。

著者の連絡先

Austin Wright（編集者）
Henry Andrews（編集者）
Ben Hutton（編集者）
Postman
URI: https://jsonschema.dev