| インターネット技術特別調査委員会 | A.ライト（編集） |
| インターネットドラフト | |
| 意図されたステータス：情報 | H.アンドリュース（編集） |
| 失効日：2020年3月20日 | |
| B.ハットン（編集） | |
| ウェルカムサンガー研究所 | |
| 2019年9月17日 |
JSONスキーマ検証：JSONの構造検証のための語彙
draft-handrews-json-schema-validation-02
JSONスキーマ（application/schema+json）にはいくつかの目的があり、そのうちの1つはJSONインスタンスの検証です。このドキュメントでは、JSONドキュメントの意味を記述し、JSONデータを操作するユーザーインターフェースのヒントを提供し、有効なドキュメントがどのようなものであるかについてアサーションを行うためのJSONスキーマの語彙を規定します。
このドラフトの課題リストは<https://github.com/json-schema-org/json-schema-spec/issues>にあります。
追加情報については、<https://json-schema.dokyumento.jp/>を参照してください。
フィードバックを提供するには、この課題追跡ツール、ホームページに記載されているコミュニケーション方法、またはドキュメント編集者にメールを送信してください。
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されています。
インターネットドラフトは、インターネット技術特別調査委員会（IETF）の作業文書です。他のグループもインターネットドラフトとして作業文書を配布する場合があることに注意してください。現在のインターネットドラフトのリストは、https://datatracker.ietf.org/drafts/current/にあります。
インターネットドラフトは最大6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置き換え、または廃止される可能性があります。インターネットドラフトを参考文献として使用したり、「作業中」として引用したりすることは適切ではありません。
このインターネットドラフトは、2020年3月20日に失効します。
Copyright (c) 2019 IETF Trustおよびドキュメントの作成者として特定された個人。All rights reserved.
このドキュメントは、BCP 78およびこのドキュメントの発行日に有効なIETF TrustのIETFドキュメントに関連する法的規定（https://trustee.ietf.org/license-info）に従います。このドキュメントに関する権利と制限を説明しているため、これらのドキュメントを注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているように、Simplified BSDライセンスのテキストを含める必要があり、Simplified BSDライセンスに記載されているように保証なしで提供されます。
JSONスキーマを使用して、特定のJSONドキュメント（インスタンス）が特定の数の基準を満たすことを要求できます。これらの基準は、この仕様で説明されているキーワードを使用してアサートされます。さらに、インタラクティブなユーザーインターフェイスインスタンスの生成を支援するためのキーワードのセットも定義されています。
この仕様では、JSONスキーマコア仕様で定義された概念、構文、および用語を使用します。
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119で説明されているように解釈されます。
この仕様では、「コンテナインスタンス」という用語は、配列とオブジェクトの両方のインスタンスを指します。また、「子インスタンス」という用語は、配列要素またはオブジェクトメンバーの値を指します。
配列値の要素は、この配列の2つの要素が等しくない場合、一意であると言われます。
JSONスキーマ検証は、インスタンスデータの構造に関する制約をアサートします。アサートされたすべての制約を満たすインスタンスの場所には、記述的なメタデータや使用法のヒントなど、アサーション以外の情報を含むキーワードが注釈として付与されます。インスタンス内のすべての場所がアサートされたすべての制約を満たしている場合、そのインスタンスはスキーマに対して有効であると言えます。
各スキーマオブジェクトは、適用される各インスタンスの場所に対して個別に評価されます。これにより、バリデーターがドキュメント全体の検証プロセスで状態を維持する必要がないことが保証されるため、バリデーターの実装要件が大幅に簡素化されます。
この仕様では、アサーションキーワードのセットと、JSONインスタンスに有用な情報を注釈として付与するために使用できるメタデータキーワードの小さな語彙を定義します。セクション7のキーワードは、主に注釈として意図されていますが、オプションでアサーションとして使用できます。セクション8のキーワードは、JSON文字列として埋め込まれたドキュメントを操作するための注釈です。
ヌル文字（\u0000）はJSON文字列で有効であることに注意してください。検証するインスタンスには、基になるプログラミング言語がそのようなデータを処理する能力に関係なく、この文字を含む文字列値が含まれている場合があります。
JSON仕様では、任意の精度を持つ数値が許可されており、JSONスキーマはそのような境界を追加しません。これは、JSONスキーマによって処理される数値インスタンスが、基になるプログラミング言語がそのようなデータを処理する能力に関係なく、任意に大きく、または任意に長い小数部を持つことができることを意味します。
正規表現を使用するキーワード、またはインスタンス値を正規表現にするように制約するキーワードは、JSONスキーマコア仕様における正規表現の相互運用性に関する考慮事項に従います。
デフォルトのJSONスキーマメタスキーマの現在のURIは、<https://json-schema.dokyumento.jp/draft/2019-09/schema>です。スキーマ作成者の便宜のために、このメタスキーマは、この仕様とJSONスキーマコア仕様で定義されているすべての語彙、および移行期間のために予約されている2つの以前のキーワードについて説明しています。個々の語彙と語彙のメタスキーマURIは、以下の各セクションに記載されています。特定の語彙は、サポートするためにオプションであり、詳細については関連セクションで説明しています。
エラーを修正するために、仕様ドラフト間で語彙とメタスキーマのURIが更新されて公開される場合があります。実装では、この仕様ドラフト以降および次の仕様ドラフトまでの日付のURIを、ここにリストされているものと同じ構文とセマンティクスを示すものとして考慮する必要があります。
スキーマの検証キーワードは、インスタンスの検証を成功させるための要件を課します。これらのキーワードはすべて、注釈動作のないアサーションです。
「$vocabulary」を使用しないメタスキーマは、そのURIがtrueの値で存在するかのように、この語彙を必須とするものと見なす必要があります。
この語彙（検証語彙）の現在のURIは次のとおりです: <https://json-schema.dokyumento.jp/draft/2019-09/vocab/validation>。
対応するメタスキーマの現在のURIは次のとおりです: <https://json-schema.dokyumento.jp/draft/2019-09/meta/validation>。
このキーワードの値は、文字列または配列のいずれかでなければなりません。配列の場合、配列の要素は文字列でなければならず、一意でなければなりません。
文字列の値は、6つの基本型（"null"、"boolean"、"object"、"array"、"number"、または"string"）のいずれか、あるいは、小数部分がゼロの任意の数値に一致する"integer"のいずれかでなければなりません。
インスタンスは、このキーワードにリストされているいずれかのセットに含まれている場合にのみ、検証に合格します。
このキーワードの値は配列でなければなりません。この配列は、少なくとも1つの要素を持つべきです。配列内の要素は一意であるべきです。
インスタンスの値が、このキーワードの配列値内の要素の1つと等しい場合、そのインスタンスはこのキーワードに対して正常に検証されます。
配列内の要素は、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"の値までの出現範囲を設定する場合にのみ役立ちます。 "maxContains"がない値0は、"contains"が常に検証に合格するようにします。
"contains"が同じスキーマオブジェクト内に存在しない場合、このキーワードは効果がありません。
このキーワードを省略した場合、値が1の場合と同じ動作になります。
このキーワードの値は、非負の整数でなければなりません。
オブジェクトインスタンスは、そのプロパティの数がこのキーワードの値以下である場合に、"maxProperties"に対して有効です。
このキーワードの値は、非負の整数でなければなりません。
オブジェクトインスタンスは、そのプロパティの数がこのキーワードの値以上である場合に、"minProperties"に対して有効です。
このキーワードを省略した場合、値が0の場合と同じ動作になります。
このキーワードの値は配列でなければなりません。この配列の要素は、存在する場合は、文字列でなければならず、一意でなければなりません。
オブジェクトインスタンスは、配列内のすべての項目がインスタンス内のプロパティの名前である場合に、このキーワードに対して有効です。
このキーワードを省略した場合、空の配列の場合と同じ動作になります。
このキーワードの値はオブジェクトでなければなりません。このオブジェクト内のプロパティは、存在する場合は、配列でなければなりません。各配列の要素は、存在する場合は、文字列でなければならず、一意でなければなりません。
このキーワードは、特定の別のプロパティが存在する場合に必須となるプロパティを指定します。これらの要件は、別のプロパティの存在に依存します。
インスタンスとこのキーワードの値の両方に名前として表示される各名前について、対応する配列内のすべての項目がインスタンス内のプロパティの名前でもある場合に、検証は成功します。
このキーワードを省略した場合、空のオブジェクトの場合と同じ動作になります。
構造検証だけでは、アプリケーションが特定の値で正しく動作することを許可するには不十分な場合があります。"format"アノテーションキーワードは、スキーマ作成者が、RFCまたはその他の外部仕様など、権威あるリソースによって正確に記述された値の固定サブセットのセマンティック情報を伝えることを可能にするために定義されています。
実装は、"format"をアノテーションに加えてアサーションとして扱い、指定されたセマンティクスへの値の適合性を検証しようとすることができます。詳細については、以下の実装要件を参照してください。
このキーワードの値は、format属性と呼ばれます。これは文字列でなければなりません。format属性は、一般的に特定のインスタンス型セットのみを検証できます。検証するインスタンスの型がこのセットに含まれていない場合、このformat属性とインスタンスの検証は成功するはずです。このセクションで定義されているすべてのformat属性は文字列に適用されますが、format属性は、コアJSONスキーマで定義されているデータモデルで定義されている任意のインスタンス型に適用するように指定できます。[CREF1]この仕様の"type"キーワードは、データモデルの一部ではない"integer"型を定義していることに注意してください。したがって、format属性は数値に限定できますが、特に整数に限定することはできません。ただし、数値フォーマットを"type"キーワードと共に値"integer"で使用したり、数値が整数でない場合に常に合格するように明示的に定義したりすることもできます。これにより、実質的に整数にのみ適用する場合と同じ動作になります。
"$vocabulary"を使用しないメタスキーマは、そのURIがfalseの値で存在する場合と同様に、この語彙を利用すると見なされるべきです。詳細については、以下の実装要件を参照してください。
この語彙（Format語彙）の現在のURIは次のとおりです: <https://json-schema.dokyumento.jp/draft/2019-09/vocab/format>。
対応するメタスキーマの現在のURIは次のとおりです: <https://json-schema.dokyumento.jp/draft/2019-09/meta/format>。
"format"キーワードは、アノテーションとして、またオプションでアサーションとして機能します。[CREF2]これはキーワードの履歴によるものであり、現在のキーワード設計原則に沿ったものではありません。このあいまいさを管理するために、上記の通り、"format"キーワードは独自の語彙で定義されています。語彙宣言のtrueまたはfalseの値は、"format"を使用するスキーマを処理するために必要な実装要件と、スキーマ作成者が依存できる動作を管理します。
実装がアノテーション収集をサポートしている場合、formatの値はアノテーションとして収集する必要があります。これにより、スキーマ検証が利用できない場合や不十分な場合に、アプリケーションレベルの検証が可能になります。
この要件は、語彙宣言のブール値、または次のセクションで説明する"format"のアサーション動作の構成の影響を受けません。[CREF3]語彙がfalseの値で宣言されている場合でもアノテーション収集を要求することは一般的ではありませんが、アサーション評価が実装されていない場合でも、アプリケーションレベルの検証を実行するというベストプラクティスを確実に可能にするために必要です。"format"はこの仕様の一部として常に存在しているため、falseの語彙宣言の場合でも実装がそれを認識していることを要求することは、負担とは見なされないと見なされます。
語彙宣言のブール値に関係なく、"format"をアサーションとして評価できる実装は、そのような評価を有効および無効にするオプションを提供する必要があります。オプションが明示的に指定されていない場合のアサーション評価の動作は、語彙宣言のブール値に依存します。
この仕様全体を実装する場合、この語彙はfalseの値（ただし、以下の詳細を参照）でサポートする必要があり、trueの値でサポートしても構いません。
語彙がfalseの値で宣言されている場合、実装は以下のようになります。[CREF4]これは、現在実装されている検証レベルが大きく異なり、一部またはすべてのフォーマット属性に対して全く検証を行わない実装も含まれるという現実と一致しています。また、アノテーションの動作のみに依存し、アプリケーションでセマンティックな検証を行うことを推奨する設計にもなっています。これは推奨されるベストプラクティスです。
語彙がtrueの値で宣言されている場合、この形式の語彙をサポートする実装は以下のようになります。[CREF5]日時のような単純なフォーマットの場合、構文検証は徹底的であることが期待されます。メールアドレスのような複雑なフォーマットの場合、様々な標準の統合であり、時間の経過とともに数多くの調整が行われ、曖昧なルールや廃止されたルールがあり、他のアプリケーションによって制限される可能性があるため、最小限の検証で十分です。例えば、インスタンス文字列に"@"が含まれていない場合は明らかに有効なメールアドレスではなく、7ビットASCII以外の文字を含む"email"または"hostname"も同様に明らかに無効です。
フォーマット属性の最小限の検証要件は、多くの属性に関連する複雑さのために、意図的に曖昧で寛容です。特に、要件は構文チェックに限定されていることに注意してください。実装がメールを送信したり、URLに接続を試みたり、フォーマットインスタンスで識別されるエンティティの存在をチェックしたりすることは期待されていません。
実装は、各フォーマットに共通の解析ライブラリを使用するか、よく知られた正規表現を使用することが推奨されます。実装は、各フォーマット属性がどのように、どの程度検証されるかを明確に文書化すべきです。
標準のコアおよび検証メタスキーマには、"$vocabulary"キーワードにfalseの値が設定されたこの語彙が含まれています。これは、デフォルトでは実装はこのキーワードをアサーションとしてサポートする必要がないためです。trueの値でフォーマット語彙をサポートすると、コードサイズが大幅に増加し、場合によっては実行時間が長くなることが理解されており、すべての実装に適しているわけではありません。
実装はカスタムフォーマット属性をサポートできます。当事者間の合意を除き、スキーマの作成者は、ピア実装がそのようなカスタムフォーマット属性をサポートすることを期待してはなりません。実装は、不明なフォーマット属性によって検証に失敗したり、処理を停止したりしてはなりません。"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"フォーマットは、URN内のUUIDではなく、プレーンなUUID用であることにも注意してください。例としては、"f81d4fae-7dec-11d0-a765-00a0c91e6bf6"です。URNとしてのUUIDの場合、"uri"フォーマットを使用し、URIスキームとURN名前空間を示す"^urn:uuid:"の"pattern"正規表現を使用してください。
この属性は文字列インスタンスに適用されます。
文字列インスタンスは、[RFC6570]に従って有効なURIテンプレート（任意のレベル）である場合に、この属性に対して有効です。
URIテンプレートはIRIに使用できることに注意してください。IRIテンプレートの個別の仕様はありません。
これらの属性は文字列インスタンスに適用されます。
絶対および相対JSONポインターの両方を許可するには、"anyOf"または"oneOf"を使用して、どちらのフォーマットのサポートも示すことができます。
この属性は文字列インスタンスに適用されます。
正規表現。これはECMA 262正規表現方言に従って有効であるべきです。
フォーマットを検証する実装は、この仕様の正規表現セクションで定義されているECMA 262の少なくともサブセットを受け入れる必要があり、すべての有効なECMA 262表現を受け入れるべきです。
このセクションで定義されているアノテーションは、インスタンスにJSON文字列でエンコードされた非JSONデータが含まれていることを示します。
これらのプロパティは、JSONデータをリッチマルチメディアドキュメントとして解釈するために必要な追加情報を提供します。コンテンツのタイプ、エンコード方法、および/または検証方法について説明します。これらは検証アサーションとしては機能しません。不正な形式の文字列エンコードされたドキュメントによって、包含インスタンスが無効と見なされることはありません。
「$vocabulary」を使用しないメタスキーマは、そのURIがtrueの値で存在するかのように、この語彙を必須とするものと見なす必要があります。
Content語彙として知られるこの語彙の現在のURIは、<https://json-schema.dokyumento.jp/draft/2019-09/vocab/content>です。
対応するメタスキーマの現在のURIは、<https://json-schema.dokyumento.jp/draft/2019-09/meta/content>です。
セキュリティとパフォーマンスの懸念、および可能なコンテンツタイプのオープンエンドな性質のため、実装はデフォルトで文字列の内容を自動的にデコード、解析、および/または検証してはなりません。これにより、包含ドキュメントを処理したコンシューマーとは異なるコンシューマーによる処理を目的とした埋め込みドキュメントのユースケースもサポートされます。
このセクションのすべてのキーワードは文字列にのみ適用され、他のデータ型には影響しません。
実装は、文字列の内容を自動的にデコード、解析、および/または検証する機能を提供してもよい（MAY）。ただし、デフォルトではこれらの操作を実行してはならず（MUST NOT）、文字列としてエンコードされた各ドキュメントの検証結果を、包含するドキュメントとは別に提供しなければなりません（MUST）。このプロセスは、インスタンスを元のスキーマに対して完全に評価し、その後アノテーションを使用して、文字列としてエンコードされた各ドキュメントをデコード、解析、および/または検証することと同等であるべきです（SHOULD）。[CREF7]今のところ、このような自動的なデコード、解析、検証機能から解析されたデータや検証結果を実行および返す正確なメカニズムは特定されていません。そのような機能が普及した場合、将来のドラフトでより詳細に規定される可能性があります。
これらのキーワードに従ってインスタンス文字列を自動的に処理することで導入される可能性のある脆弱性については、セキュリティに関する考慮事項セクションも参照してください。
インスタンスの値が文字列の場合、このプロパティは、文字列をバイナリデータとして解釈し、このプロパティで指定されたエンコーディングを使用してデコードする必要がある（SHOULD）ことを定義します。
このプロパティに使用できる値は、RFC 2045、Sec 6.1およびRFC 4648にリストされています。両方のRFCで定義されている「base64」については、行の長さの制限を削除したRFC 4648の定義を使用するべきです（SHOULD）。他のさまざまな仕様で異なる長さが義務付けられているためです。文字列内の行の長さは、「pattern」キーワードを使用して制約できることに注意してください。
このキーワードが存在しないが、「contentMediaType」が存在する場合、これは、メディアタイプが他のJSON文字列値と同様にUTF-8にエンコード可能であり、追加のデコードを必要としないことを示します。
このプロパティの値は文字列である必要があります（MUST）。
インスタンスが文字列の場合、このプロパティは文字列の内容のメディアタイプを示します。「contentEncoding」が存在する場合、このプロパティはデコードされた文字列を記述します。
このプロパティの値は文字列である必要があり（MUST）、RFC 2046で定義されているメディアタイプである必要があります（MUST）。
インスタンスが文字列であり、「contentMediaType」が存在する場合、このプロパティには、文字列の構造を記述するスキーマが含まれています。
このキーワードは、JSON Schemaのデータモデルにマッピングできる任意のメディアタイプで使用できます（MAY）。
このプロパティの値は、「contentMediaType」が存在しない場合は無視するべきです（SHOULD）。
これは、「contentEncoding」と「contentMediaType」の使用を示すスキーマの例です。
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
このスキーマによって記述されるインスタンスは文字列であると予想され、その値はbase64エンコードされたPNG画像として解釈できる必要があります。
別の例
{
"type": "string",
"contentMediaType": "text/html"
}
このスキーマによって記述されるインスタンスは、JSON文字列がデコードされた文字セットを使用してHTMLを含む文字列であることが予想されます。RFC 8259のセクション8.1によると、完全に閉じたシステム以外では、これはUTF-8である必要があります（MUST）。
この例では、HMAC SHA-256アルゴリズムを使用してMACされた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文字列がどのように2つのJSONデータ構造（最初にヘッダー、次にペイロード）のリストにデコードされるかを決定します。JWTメディアタイプは、JWTがJSON文字列で表現できることを保証するため、追加のエンコードまたはデコードは必要ありません。
これらの汎用アノテーションキーワードは、ドキュメントとユーザーインターフェイスの表示目的で一般的に使用される情報を提供します。それらは、包括的な機能セットを形成することを意図したものではありません。むしろ、より複雑なアノテーションベースのアプリケーションに対して追加の語彙を定義できます。
「$vocabulary」を使用しないメタスキーマは、そのURIがtrueの値で存在するかのように、この語彙を必須とするものと見なす必要があります。
メタデータ語彙として知られるこの語彙の現在のURIは次のとおりです：<https://json-schema.dokyumento.jp/draft/2019-09/vocab/meta-data>。
対応するメタスキーマの現在のURIは次のとおりです：<https://json-schema.dokyumento.jp/draft/2019-09/meta/meta-data>。
これらのキーワードの値はどちらも文字列である必要があります（MUST）。
これらのキーワードはどちらも、このユーザーインターフェイスによって生成されたデータに関する情報をユーザーインターフェイスに装飾するために使用できます。タイトルは短いことが望ましいですが、説明は、このスキーマで記述されたインスタンスの目的に関する説明を提供します。
このキーワードの値に制限はありません。このキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、実装は重複を削除するべきです（SHOULD）。
このキーワードは、特定のスキーマに関連付けられたデフォルトのJSON値を提供するために使用できます。デフォルト値は、関連付けられたスキーマに対して有効であるように推奨されます（RECOMMENDED）。
このキーワードの値はブール値である必要があります（MUST）。このキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、アプリケーションは、いずれかの出現がtrue値を指定している場合は、インスタンスの場所が非推奨であると見なす必要があります（SHOULD）。
「deprecated」の値がブール値のtrueである場合、アプリケーションは宣言されたプロパティの使用を控えるべきである（SHOULD）ことを示します。それは、プロパティが将来削除される可能性があることを意味するかもしれません。
trueの値を持つ「deprecated」を含むルートスキーマは、記述されているリソース全体が将来削除される可能性がある（MAY）ことを示します。
「deprecated」キーワードが「items」によって配列内の項目に適用される場合、「items」が単一のスキーマである場合は、非推奨は配列全体に関係し、「items」がスキーマの配列である場合は、非推奨はサブスキーマの位置に従って対応する項目に関係します。
このキーワードを省略した場合、値がfalseの場合と同じ動作になります。
これらのキーワードの値はブール値である必要があります（MUST）。これらのキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、結果の動作は、いずれかの出現がtrue値を指定している場合はtrue値の場合と同様であるべきで（SHOULD）、それ以外の場合はfalse値の場合と同様であるべきです（SHOULD）。
「readOnly」の値がブール値のtrueである場合、インスタンスの値は所有する権限によって排他的に管理されており、アプリケーションがこのプロパティの値を変更しようとすると、その所有する権限によって無視または拒否されると予想されることを示します。
ドキュメント全体で「readOnly」としてマークされたインスタンスドキュメントは、所有する権限に送信された場合は無視されるか、権限の裁量でエラーになる可能性があります（MAY）。
「writeOnly」の値がブール値のtrueである場合、インスタンスが所有する権限から取得されたときに値が存在しないことを示します。ドキュメント（またはそれが表すリソース）を更新または作成するために所有する権限に送信する場合は存在できますが、インスタンスの更新または新しく作成されたバージョンには含まれません。
ドキュメント全体で「writeOnly」としてマークされたインスタンスドキュメントは、何らかの種類の空白ドキュメントとして返されるか、取得時にエラーが発生するか、権限の裁量で取得要求が無視される可能性があります（MAY）。
たとえば、「readOnly」はデータベースで生成されたシリアル番号を読み取り専用としてマークするために使用され、「writeOnly」はパスワード入力フィールドをマークするために使用されます。
これらのキーワードは、ユーザーインターフェイスのインスタンス生成を支援するために使用できます。特に、アプリケーションは、書き込み専用フィールドの場合、入力値が入力されるにつれて隠すウィジェットを使用することを選択できます（MAY）。
これらのキーワードを省略すると、falseの値と同じ動作になります。
このキーワードの値は配列である必要があります（MUST）。配列内の値に制限はありません。このキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、実装は、配列の配列ではなく、すべての値のフラットな配列を提供する必要があります（MUST）。
このキーワードは、使用例を示す目的で、特定のスキーマに関連付けられたサンプルJSON値を提供するために使用できます。これらの値は、関連付けられたスキーマに対して有効であるように推奨されます（RECOMMENDED）。
実装は、「default」の値（存在する場合）を追加の例として使用できます（MAY）。「examples」が存在しない場合でも、「default」はこのように使用できます（MAY）。
JSON Schema検証は、JSON Schemaコアの語彙を定義し、そこにリストされているすべてのセキュリティに関する考慮事項に関係します。
JSON Schema検証では、正規表現の使用が許可されており、これには多数の異なる（多くの場合、互換性のない）実装があります。一部の実装では、任意のコードの埋め込みが許可されていますが、これはJSON Schemaの範囲外であり、許可されてはなりません（MUST NOT）。正規表現は、計算コストが非常に高くなるように（いわゆる「壊滅的なバックトラッキング」を伴って）作成することもでき、サービス拒否攻撃につながる可能性があります。
「contentEncoding」および/または「contentMediaType」に基づいてインスタンス文字列データを検証または評価することをサポートする実装は、誤解を招く情報に基づいて安全でない方法でデータを評価するリスクがあります。アプリケーションは、スキーマとインスタンスの間に関係が確立されている場合（たとえば、同じ権限を共有している場合）にのみこのような処理を実行することで、このリスクを軽減できます。
メディアタイプまたはエンコーディングの処理は、そのメディアタイプまたはエンコーディングのセキュリティに関する考慮事項の影響を受けます。たとえば、JSON文字列内にエンコードされたJavaScriptまたはECMAScriptを処理するときは、RFC 4329 Scripting Media Typesのセキュリティに関する考慮事項が適用されます。
| [ecma262] | 「ECMA 262 仕様」 |
| [json-schema] | Wright, A. and 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. and 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. and N. Borenstein, "多目的インターネットメール拡張（MIME）パート1：インターネットメッセージ本体の形式", RFC 2045, DOI 10.17487/RFC2045, 1996年11月. |
| [RFC2046] | Freed, N. and N. Borenstein, "多目的インターネットメール拡張（MIME）パート2：メディアタイプ", 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. and C. Newman, "インターネット上の日付と時刻：タイムスタンプ", RFC 3339, DOI 10.17487/RFC3339, 2002年7月. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier（URI）：ジェネリック構文", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月. |
| [RFC3987] | Duerst, M. and M. Suignard, "国際化リソース識別子（IRI）", RFC 3987, DOI 10.17487/RFC3987, 2005年1月. |
| [RFC4122] | Leach, P., Mealling, M. and R. Salz, "汎用一意識別子（UUID）URNネームスペース", RFC 4122, DOI 10.17487/RFC4122, 2005年7月. |
| [RFC4291] | Hinden, R. and 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 Object Notation (JSON) ポインタ", RFC 6901, DOI 10.17487/RFC6901, 2013年4月. |
| [RFC8259] | Bray, T., "JavaScript Object Notation (JSON) データ交換形式", STD 90, RFC 8259, DOI 10.17487/RFC8259, 2017年12月. |
| [RFC4329] | Hoehrmann, B., "スクリプトメディアタイプ", RFC 4329, DOI 10.17487/RFC4329, 2006年4月. |
このドキュメントから、いくつかのキーワードがこのドラフトの時点でコア仕様に移動しました。場合によっては、名前の変更やその他の変更が行われています。これは、以前のバリデーションキーワードに影響します。
JSON Schema の最初のドラフトにご尽力いただいた Gary Court 氏、Francis Galiegue 氏、Kris Zyp 氏、Geraint Luff 氏に感謝します。
ドキュメントへの提出とパッチにご協力いただいた Jason Desrosiers 氏、Daniel Perrett 氏、Erik Wilde 氏、Ben Hutton 氏、Evgeny Poberezkin 氏、Brad Bowman 氏、Gowry Sankar 氏、Donald Pipowitch 氏、Dave Finlay 氏、Denis Laxalde 氏に感謝します。
[CREF8]このセクションは、インターネットドラフトのステータスを離れる前に削除されます。