| インターネット技術特別調査委員会 | 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/>を参照してください。
フィードバックを提供するには、このIssue Tracker、ホームページに記載されているコミュニケーション方法、またはドキュメント編集者に電子メールで連絡してください。
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されます。
インターネットドラフトは、インターネット技術特別調査委員会（IETF）の作業文書です。他のグループもインターネットドラフトとして作業文書を配布することがあることに注意してください。現在のインターネットドラフトのリストは、https://datatracker.ietf.org/drafts/current/ にあります。
インターネットドラフトは、最大6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。インターネットドラフトを参考資料として使用したり、「作業中」以外の引用をすることは不適切です。
このインターネットドラフトは、2020年3月20日に失効します。
Copyright (c) 2019 IETF Trustおよびドキュメント作成者として特定された人物。無断複写・転載を禁じます。
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETF TrustのIETFドキュメントに関する法的規定（https://trustee.ietf.org/license-info）に準拠します。このドキュメントに関する権利と制限について説明されているため、これらのドキュメントを注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されている簡略化されたBSDライセンステキストを含める必要があり、簡略化された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つの要素を持つべきです。配列の要素は一意であるべきです。
インスタンスの値が、このキーワードの配列値の要素のいずれかに等しい場合、インスタンスはこのキーワードに対して正常に検証されます。
配列内の要素は、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の値は許可されていますが、「maxContains」の値によって0から出現範囲を設定する場合にのみ役立ちます。「maxContains」がない状態で0の値を指定すると、「contains」は常に検証に合格します。
「contains」が同じスキーマオブジェクト内に存在しない場合、このキーワードは効果がありません。
このキーワードを省略すると、値が1の場合と同じ動作になります。
このキーワードの値は、非負の整数でなければなりません。
オブジェクトインスタンスは、プロパティの数がこのキーワードの値以下の場合、「maxProperties」に対して有効です。
このキーワードの値は、非負の整数でなければなりません。
オブジェクトインスタンスは、プロパティの数がこのキーワードの値以上の場合、「minProperties」に対して有効です。
このキーワードを省略すると、値が0の場合と同じ動作になります。
このキーワードの値は、配列でなければなりません。この配列の要素（存在する場合）は文字列でなければならず、かつ一意でなければなりません。
オブジェクトインスタンスは、配列内のすべての項目がインスタンス内のプロパティの名前である場合、このキーワードに対して有効です。
このキーワードを省略すると、空の配列と同じ動作になります。
このキーワードの値は、オブジェクトでなければなりません。このオブジェクトのプロパティ（存在する場合）は、配列でなければなりません。各配列内の要素（存在する場合）は文字列でなければならず、かつ一意でなければなりません。
このキーワードは、特定の別のプロパティが存在する場合に必要なプロパティを指定します。これらの要件は、他のプロパティの存在に依存します。
インスタンスとこのキーワードの値の両方に名前として表示される各名前について、対応する配列内のすべての項目もインスタンス内のプロパティの名前である場合、検証は成功します。
このキーワードを省略すると、空のオブジェクトと同じ動作になります。
構造的な検証だけでは、アプリケーションが特定の値を正しく利用できるようにするには不十分な場合があります。「format」アノテーションキーワードは、スキーマ作成者が、RFCやその他の外部仕様などの信頼できるリソースによって正確に記述されている値の固定されたサブセットに対してセマンティック情報を伝えることができるように定義されています。
実装では、「format」をアノテーションに加えてアサーションとして扱い、指定されたセマンティクスへの値の適合性を検証しようとする場合があります。詳細については、以下の実装要件を参照してください。
このキーワードの値は、形式属性と呼ばれます。文字列でなければなりません。形式属性は通常、特定のインスタンス型のセットのみを検証できます。検証するインスタンスの型がこのセットに含まれていない場合、この形式属性およびインスタンスの検証は成功するはずです。このセクションで定義されているすべての形式属性は文字列に適用されますが、形式属性は、コアJSONスキーマで定義されているデータモデルで定義された任意のインスタンス型に適用するように指定できます。[CREF1]この仕様の「type」キーワードは、データモデルの一部ではない「integer」型を定義していることに注意してください。したがって、形式属性は数値に制限できますが、特に整数には制限できません。ただし、数値形式は、「integer」の値を持つ「type」キーワードと一緒に使用できます。または、数値が整数でない場合は常に合格するように明示的に定義できます。これにより、整数にのみ適用するのと実質的に同じ動作が生成されます。
「$vocabulary」を使用しないメタスキーマは、そのURIがfalseの値で存在する場合と同様に、この語彙を利用すると見なされるべきです。詳細については、以下の実装要件を参照してください。
この語彙（形式語彙として知られています）の現在の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」のアサーション動作の構成の影響を受けません。[CREF3]語彙がfalseの値で宣言されている場合でも注釈コレクションを要求することは一般的ではありませんが、アサーション評価が実装されていない場合でも、アプリケーションレベルの検証を実行するというベストプラクティスを確実に実行できるようにするために必要です。「format」はこの仕様の一部として常に存在してきたため、語彙がfalseで宣言されている場合でも実装がそれを認識していることを要求することは、負担とは見なされません。
語彙宣言のブール値に関係なく、「format」をアサーションとして評価できる実装は、そのような評価を有効または無効にするオプションを提供する必要があります。オプションが明示的に指定されていない場合のアサーション評価の動作は、語彙宣言のブール値に依存します。
この仕様全体を実装する場合、この語彙はfalseの値でサポートする必要があります（ただし、以下の詳細を参照してください）。trueの値でサポートしても構いません。
語彙がfalseの値で宣言されている場合、実装は次のようになります。[CREF4]これは、一部またはすべてのformat属性に対して、まったく検証を行わないなど、検証レベルが大きく異なる実装の現状と一致しています。また、アノテーション動作のみに依存し、アプリケーションでセマンティック検証を実行することを推奨するベストプラクティスを奨励するように設計されています。
語彙がtrueの値で宣言されている場合、この形式の語彙をサポートする実装は次のようになります。[CREF5]日時などの単純な形式の場合、構文検証が徹底されることが期待されます。さまざまな規格と、時間の経過に伴う多数の調整、および値を活用する他のアプリケーションによって制限される可能性のある不明瞭なルールや廃止されたルールが混在しているメールアドレスのような複雑な形式の場合、最小限の検証で十分です。たとえば、「@」が含まれていないインスタンス文字列は明らかに有効なメールアドレスではなく、7ビットASCII以外の文字を含む「メール」または「ホスト名」も同様に明らかに無効です。
format属性の最小限の検証の要件は、多くの場合の複雑さを考慮して、意図的に曖昧で許容的です。特に、要件は構文チェックに限定されていることに注意してください。実装が電子メールを送信したり、URLに接続を試みたり、その他にformatインスタンスによって識別されるエンティティの存在を確認したりすることは期待されていません。
実装では、各formatに共通の解析ライブラリ、またはよく知られた正規表現を使用することをお勧めします。実装では、各format属性がどのように、どの程度検証されるかを明確に文書化する必要があります。
標準のコアおよび検証メタスキーマには、デフォルトでは実装がこのキーワードをアサーションとしてサポートする必要がないため、"$vocabulary"キーワードにfalseの値でこの語彙が含まれています。format語彙をtrueの値でサポートすると、コードサイズが大幅に増加し、場合によっては実行時間も増加することが理解されており、すべての実装に適しているわけではありません。
実装は、カスタムformat属性をサポートしても構いません。当事者間の合意がない限り、スキーマ作成者はピア実装がそのようなカスタムformat属性をサポートすることを期待してはなりません。実装は、不明なformat属性のために検証に失敗したり、処理を停止したりしてはなりません。「format」をアノテーションとして扱う場合、実装は既知および不明なformat属性の両方の値を収集する必要があります。
語彙は、キーワードに対して異なる値セットを具体的に宣言することをサポートしていません。この制限と、このキーワードの実装が歴史的に不均一であるため、相互運用性が必要な場合は、追加のformat属性ではなく、カスタム語彙で追加のキーワードを定義することをお勧めします。
これらの属性は、文字列インスタンスに適用されます。
日付と時刻のformat名は、RFC 3339、セクション5.6から派生しています。期間のformatは、RFC 3339の付録Aに記載されているISO 8601 ABNFからのものです。
形式をサポートする実装は、次の属性のサポートを実装する必要があります
実装は、そのセクションで定義されている他のプロダクション名を使用して、追加の属性をサポートしても構いません。「full-date」または「full-time」が実装されている場合、対応する短い形式（それぞれ「date」または「time」）を実装する必要があり、同一の動作をする必要があります。実装は、そのプロダクションのルールに従って検証しない限り、RFC 3339プロダクションに一致する名前の拡張属性を定義しないでください。[CREF6]現在、すべてのRFC 3339形式をサポートする必要性についてコンセンサスがないため、この名前空間を予約するアプローチは、セット全体にコミットすることなく実験を奨励します。formatの実装要件は一般的に柔軟になるか、これらは完全に指定された属性に昇格するか、削除されるかのいずれかになるでしょう。
これらの属性は、文字列インスタンスに適用されます。
文字列インスタンスは、以下のように有効なインターネットメールアドレスである場合、これらの属性に対して有効です
「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ポインターと相対JSONポインターの両方を許可するには、「anyOf」または「oneOf」を使用して、どちらかの形式のサポートを示します。
この属性は、文字列インスタンスに適用されます。
正規表現。これは、ECMA 262正規表現方言に従って有効である必要があります。
形式を検証する実装は、この仕様の正規表現セクションで定義されているECMA 262の少なくともサブセットを受け入れる必要があり、すべての有効なECMA 262式を受け入れる必要があります。
このセクションで定義されているアノテーションは、インスタンスにJSON文字列でエンコードされた非JSONデータが含まれていることを示しています。
これらのプロパティは、JSONデータをリッチなマルチメディアドキュメントとして解釈するために必要な追加情報を提供します。コンテンツのタイプ、エンコード方法、および検証方法について記述します。これらは検証アサーションとしては機能しません。不正な形式の文字列エンコードされたドキュメントであっても、それを含むインスタンスが無効と見なされることはありません。
"$vocabulary"を使用しないメタスキーマは、そのURIが存在し、値がtrueであるかのように、この語彙を必須とするものと見なす必要があります。
コンテンツ語彙として知られるこの語彙の現在の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）、各文字列エンコードドキュメントの検証結果を、囲んでいるドキュメントとは別に提供する必要があります。このプロセスは、インスタンスを元のスキーマに対して完全に評価した後、アノテーションを使用して各文字列エンコードドキュメントをデコード、解析、または検証することと同等であるべきです（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スキーマのデータモデルにマッピングできる任意のメディアタイプで使用できます（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の場合、アプリケーションは宣言されたプロパティの使用を控えるべきであることを示します。これは、プロパティが将来削除される可能性があることを意味します（MAY）。
値がtrueの「deprecated」を含むルートスキーマは、記述されているリソース全体が将来削除される可能性があることを示します（MAY）。
「deprecated」キーワードが「items」によって配列内の項目に適用される場合、「items」が単一のスキーマである場合は、非推奨が配列全体に関連し、「items」がスキーマの配列である場合は、非推奨がサブスキーマの位置に従って対応する項目に関連します。
このキーワードを省略すると、値がfalseの場合と同じ動作になります。
これらのキーワードの値はブール値である必要があります（MUST）。これらのキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、いずれかの出現でtrue値が指定された場合はtrue値の場合と同じ動作になり、それ以外の場合はfalse値の場合と同じ動作になるはずです（SHOULD）。
「readOnly」の値がブール値のtrueの場合、インスタンスの値が所有権限によって排他的に管理され、アプリケーションがこのプロパティの値を変更しようとすると、その所有権限によって無視または拒否されることが予想されます。
ドキュメント全体に対して「readOnly」としてマークされているインスタンスドキュメントは、所有権限に送信された場合、無視されるか（MAY）、所有権限の裁量でエラーになるか（MAY）します。
「writeOnly」の値がブール値のtrueの場合、インスタンスが所有権限から取得されるときに値が存在しないことを示します。ドキュメント（またはそれが表すリソース）を更新または作成するために所有権限に送信するときに存在できますが、インスタンスの更新または新しく作成されたバージョンには含まれません。
ドキュメント全体に対して「writeOnly」としてマークされているインスタンスドキュメントは、ある種の空白ドキュメントとして返されるか（MAY）、取得時にエラーが発生するか（MAY）、または取得リクエストが無視される可能性があります（MAY）。これは権限の裁量に委ねられます。
たとえば、「readOnly」はデータベースで生成されたシリアル番号を読み取り専用としてマークするために使用され、「writeOnly」はパスワード入力フィールドをマークするために使用されます。
これらのキーワードは、ユーザーインターフェイスのインスタンスの生成を支援するために使用できます。特に、アプリケーションは、書き込み専用フィールドで入力値が入力時に非表示になるウィジェットを使用することを選択できます（MAY）。
これらのキーワードを省略すると、falseの値と同じ動作になります。
このキーワードの値は配列である必要があります（MUST）。配列内の値に制限はありません。このキーワードの複数の出現が単一のサブインスタンスに適用可能な場合、実装は、配列の配列ではなく、すべての値のフラットな配列を提供する必要があります（MUST）。
このキーワードは、使用法を説明する目的で、特定のスキーマに関連付けられたサンプルJSON値を提供するために使用できます。これらの値が関連付けられたスキーマに対して有効であることが推奨されます（RECOMMENDED）。
実装は、存在する場合、「default」の値を追加の例として使用できます（MAY）。「examples」が存在しない場合、「default」はこの方法で使用できます（MAY）。
JSONスキーマの検証では、JSONスキーマコアの語彙を定義し、そこにリストされているすべてのセキュリティに関する考慮事項に関係します。
JSONスキーマの検証では、多数の異なる（多くの場合互換性のない）実装を持つ正規表現の使用を許可しています。一部の実装では、JSONスキーマの範囲外であり、許可してはならない（MUST NOT）任意のコードの埋め込みが許可されています。正規表現は、計算に非常にコストがかかる（いわゆる「壊滅的なバックトラッキング」による）、サービス拒否攻撃につながるように作成されることもよくあります。
「contentEncoding」または「contentMediaType」に基づいてインスタンス文字列データを検証または評価することをサポートする実装は、誤解を招く情報に基づいて安全でない方法でデータを評価するリスクがあります。アプリケーションは、スキーマとインスタンスの関係が確立されている場合（たとえば、同じ権限を共有する場合）にのみこのような処理を実行することで、このリスクを軽減できます。
メディアタイプまたはエンコーディングの処理には、そのメディアタイプまたはエンコーディングのセキュリティに関する考慮事項が適用されます。たとえば、JSON文字列内にエンコードされたJavaScriptまたはECMAScriptを処理する場合は、RFC 4329 スクリプトメディアタイプのセキュリティに関する考慮事項が適用されます。
| [ecma262] | "ECMA 262 仕様" |
| [json-schema] | Wright, A. and H. Andrews, "JSONスキーマ：JSONドキュメントを記述するためのメディアタイプ", Internet-Draft draft-handrews-json-schema-02, 2017年11月。 |
| [relative-json-pointer] | Luff, G. and H. Andrews, "相対JSONポインタ", 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, "Multipurpose Internet Mail Extensions（MIME）パート1：インターネットメッセージ本体の形式", RFC 2045, DOI 10.17487/RFC2045, 1996年11月。 |
| [RFC2046] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions（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, "Universally Unique IDentifier (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. and W. Mao, "国際化メールのためのSMTP拡張", RFC 6531, DOI 10.17487/RFC6531, 2012年2月. |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. and D. Orchard, "URIテンプレート", RFC 6570, DOI 10.17487/RFC6570, 2012年3月. |
| [RFC6901] | Bryan, P., Zyp, K. and 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]このセクションは、インターネットドラフトのステータスを離れる前に削除されます。