| インターネット技術特別調査委員会 | A.ライト（編） |
| インターネットドラフト | |
| 意図されたステータス：情報 | H.アンドリュース（編） |
| 有効期限：2018年9月20日 | Cloudflare, Inc. |
| 2018年3月19日 |
JSONスキーマ：JSONドキュメントを記述するためのメディアタイプ
draft-handrews-json-schema-01
JSONスキーマは、JSONデータの構造を記述するためのJSONベースのフォーマットであるメディアタイプ「application/schema+json」を定義します。JSONスキーマは、JSONドキュメントがどのような外観でなければならないか、そこから情報を抽出する方法、およびそれとどのように対話するかをアサートします。「application/schema-instance+json」メディアタイプは、「application/json」ドキュメントに提供できる以上の、「application/schema+json」との機能豊富な統合を提供します。
このドラフトに関する問題リストは、<https://github.com/json-schema-org/json-schema-spec/issues>にあります。
追加情報については、<https://json-schema.dokyumento.jp/>を参照してください。
フィードバックを提供するには、この問題追跡システム、ホームページに記載されているコミュニケーション方法、またはドキュメントエディターにメールしてください。
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されています。
インターネットドラフトは、インターネット技術特別調査委員会（IETF）の作業文書です。他のグループもインターネットドラフトとして作業文書を配布する場合があることに注意してください。現在のインターネットドラフトのリストは、http://datatracker.ietf.org/drafts/current/にあります。
インターネットドラフトは、最大6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。インターネットドラフトを参照資料として使用したり、「作業中」以外のものとして引用したりすることは不適切です。
このインターネットドラフトは、2018年9月20日に失効します。
Copyright（c）2018 IETF Trustおよびドキュメント作成者として特定された個人。全著作権所有。
このドキュメントは、BCP 78およびこのドキュメントの公開日に有効なIETF TrustのIETFドキュメントに関する法的規定（http://trustee.ietf.org/license-info）に従います。これらのドキュメントには、このドキュメントに関する権利と制限が記載されているため、注意して確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストを含める必要があり、Simplified BSD Licenseに記載されているように、保証なしで提供されます。
JSONスキーマは、JSONデータの構造を定義するためのJSONメディアタイプです。JSONスキーマは、JSONデータの検証、ドキュメント化、ハイパーリンクナビゲーション、および対話制御を定義することを目的としています。
この仕様では、参照による別のJSONスキーマのポイント、JSONスキーマ参照の逆参照、および使用される語彙の指定など、JSONスキーマのコア用語とメカニズムを定義します。
その他の仕様では、検証、リンク、アノテーション、ナビゲーション、および対話に関するアサーションを実行する語彙を定義します。
このドキュメントにおけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [RFC2119]に記載されているように解釈されます。
このドキュメントにおける用語「JSON」、「JSONテキスト」、「JSON値」、「メンバー」、「要素」、「オブジェクト」、「配列」、「数値」、「文字列」、「ブール値」、「true」、「false」、および「null」は、RFC 7159 [RFC7159]で定義されているように解釈されます。
このドキュメントでは、JSONデータを記述するためのJSONスキーマを識別するために、新しいメディアタイプ「application/schema+json」を提案します。また、追加の統合機能を提供するために、さらにオプションのメディアタイプ「application/schema-instance+json」を提案します。JSONスキーマ自体はJSONドキュメントです。これと関連する仕様では、作成者がJSONデータをいくつかの方法で記述できるキーワードを定義します。
JSONスキーマは、JSONドキュメントの構造（たとえば、必須プロパティと長さの制限）を記述します。アプリケーションはこの情報を使用して、インスタンスを検証したり（制約が満たされていることを確認）、制約が満たされるようにユーザー入力を収集するインターフェイスに通知したりできます。
検証の動作とキーワードは、別のドキュメント [json-schema-validation]で指定されています。
JSONスキーマは、インスタンスがアノテーションを含むスキーマオブジェクト、およびそのすべての親スキーマオブジェクトに対して検証されるたびに、情報でインスタンスをアノテーションできます。
詳細なアノテーション動作と、基本的なアノテーションキーワードの小さなセットは、検証仕様 [json-schema-validation]で定義されています。
JSONハイパースキーマは、JSONドキュメントのハイパーテキスト構造を記述します。これには、インスタンスから他のリソースへのリンク関係、インスタンスのマルチメディアデータとしての解釈、およびAPIを使用するために必要な送信データが含まれます。
ハイパースキーマの動作とキーワードは、別のドキュメント [json-hyper-schema]で指定されています。
JSONドキュメントは、application/jsonメディアタイプで記述された情報リソース（オクテットの連続）です。
JSONスキーマでは、「JSONドキュメント」、「JSONテキスト」、および「JSON値」という用語は、定義するデータモデルのために交換可能です。
JSONスキーマは、JSONドキュメントに対してのみ定義されています。ただし、JSONスキーマデータモデルに従って解析または処理できるドキュメントまたはメモリ構造は、CBOR [RFC7049]などのメディアタイプを含め、JSONスキーマに対して解釈できます。
スキーマが適用されるJSONドキュメントは、「インスタンス」と呼ばれます。
JSONスキーマは、データモデルに従ってドキュメントを解釈します。このデータモデルに従って解釈されたJSON値を「インスタンス」と呼びます。
インスタンスには6つのプリミティブタイプのいずれかがあり、タイプに応じて可能な値の範囲があります
したがって、データモデル内で等しい数値の異なる字句表現を含む、空白とフォーマットに関する考慮事項は、JSONスキーマの範囲外です。JSONスキーマの語彙 [vocabulary]で、そのような字句表現の違いを操作する場合は、元のJSON表現のUnicode文字をそのまま使用するのではなく、データモデル内でフォーマットされた文字列を正確に解釈するためのキーワードを定義する必要があります。
オブジェクトには同じキーを持つ2つのプロパティを含めることはできないため、単一のオブジェクトで同じキー（「文字列」生成）を持つ2つのプロパティ（「メンバー」生成）を定義しようとするJSONドキュメントの動作は未定義です。
JSONスキーマ語彙は、独自の拡張型システムを自由に定義できることに注意してください。これは、ここで定義されているコアデータモデルタイプと混同しないでください。例として、「整数」は語彙がキーワードの値として定義するのに妥当なタイプですが、データモデルでは整数と他の数値を区別していません。
JSONスキーマは、「application/json」ドキュメント、および「+json」構造化構文サフィックスを使用するメディアタイプで完全に動作するように設計されています。
スキーマを操作するのに便利な一部の機能は、各メディアタイプ、つまりメディアタイプパラメータとURIフラグメント識別子構文とセマンティクスによって定義されます。これらの機能は、それぞれコンテンツネゴシエーションとインスタンス内の特定の場所のURIを計算するのに役立ちます。
この仕様では、インスタンスの作成者がこれらの目的のためにパラメータとフラグメント識別子を最大限に活用できるようにするために、「application/schema-instance+json」メディアタイプを定義します。
2つのJSONインスタンスは、同じタイプであり、データモデルに従って同じ値を持つ場合にのみ等しいと言えます。具体的には、これは次のことを意味します
この定義で暗黙的に示されているのは、配列は同じ長さである必要があり、オブジェクトは同じ数のメンバーを持つ必要があり、オブジェクト内のプロパティは順序付けされておらず、同じキーを持つ複数のプロパティを定義する方法はなく、単なるフォーマットの違い（インデント、コンマの配置、末尾のゼロ）は重要ではないということです。
JSON Schemaドキュメント、または単にスキーマとは、インスタンスを記述するために使用されるJSONドキュメントです。スキーマ自体はインスタンスとして解釈されますが、"application/schema-instance+json" ではなく、常に "application/schema+json" というメディアタイプを与える必要があります。"application/schema+json" メディアタイプは、"application/schema-instance+json" によって提供されるメディアタイプのパラメータとフラグメント識別子の構文およびセマンティクスの上位集合を提供するように定義されています。
JSON Schemaは、オブジェクトまたはブール値である必要があります。
インスタンスに適用されるオブジェクトプロパティは、キーワードまたはスキーマキーワードと呼ばれます。大まかに言って、キーワードは次の2つのカテゴリのいずれか、または両方に分類されます。
キーワードは、どちらか一方または両方のカテゴリに分類される場合があります。拡張キーワード（このドキュメントとその付属書の外で定義されたもの）は、他の動作も自由に定義できます。
ブール値スキーマの値 "true" と "false" は、インスタンスの値に関係なく常に自身を返す自明なアサーションです。例として、検証語彙の観点から、ブール値スキーマは次の動作と同等です。
JSON Schemaには、スキーマキーワードではないプロパティが含まれている場合があります。不明なキーワードは無視する必要があります。
空のスキーマは、プロパティがない、または不明なプロパティのみを持つJSON Schemaです。
JSON Schema語彙とは、特定の目的のために定義されたキーワードのセットです。語彙は、キーワードの意味をアサーション、アノテーション、および／または語彙で定義されたキーワードカテゴリとして指定します。このドキュメントの2つの付属標準は、それぞれ語彙を定義しています。1つはインスタンス検証用で、もう1つはハイパーメディアアノテーション用です。語彙は、JSON Schemaメディアタイプ内の拡張性の主要なメカニズムです。
語彙は、任意のエンティティによって定義できます。語彙の作成者は、その語彙が広く使用され、他の語彙と組み合わされる可能性がある場合は、キーワード名の衝突を避けるように注意する必要があります。JSON Schemaは、正式な名前空間システムを提供していませんが、キーワード名を制約しないため、任意の数の名前空間アプローチが可能です。
語彙は、他の語彙のキーワードの動作に関してキーワードの動作を定義したり、別の語彙のキーワードを制限または拡張された許容値のセットで使用したりするなど、相互に構築できます。そのような語彙の再利用のすべてが、それが構築された語彙と互換性のある新しい語彙になるわけではありません。語彙の作成者は、期待される互換性のレベル（ある場合）を明確に文書化する必要があります。
スキーマ自体を記述するスキーマは、メタスキーマと呼ばれます。メタスキーマは、JSON Schemaを検証し、使用している語彙を指定するために使用されます。[CREF1]現在、1つのスキーマに指定できるメタスキーマは1つのみです。つまり、複数の語彙を使用するには、それらすべてを網羅するメタスキーマを作成する必要があります。ハイパースキーマメタスキーマは、検証語彙とハイパーメディア語彙を包含するため、この例です。
ルートスキーマは、問題のJSONドキュメント全体を構成するスキーマです。
一部のキーワードはスキーマ自体を受け入れるため、JSON Schemaをネストできます。
{
"title": "root",
"items": {
"title": "array item"
}
}
このドキュメント例では、「array item」というタイトルのスキーマはサブスキーマであり、「root」というタイトルのスキーマはルートスキーマです。
ルートスキーマと同様に、サブスキーマはオブジェクトまたはブール値のいずれかです。
[RFC6839] のセクション3.1に従い、任意の +json メディアタイプに指定されたフラグメント識別子の構文とセマンティクスは、"application/json" に指定されたものと一致する必要があります。（このドキュメントの公開時点では、"application/json" に定義されたフラグメント識別構文はありません。）
さらに、"application/schema+json" メディアタイプは、プレーン名とJSONポインタの2つのフラグメント識別子構造をサポートしています。"application/schema-instance+json" メディアタイプは、JSONポインタの1つのフラグメント識別子構造をサポートしています。
URIフラグメント識別子としてのJSONポインタの使用については、RFC 6901 [RFC6901] で説明されています。2つのフラグメント識別構文をサポートする "application/schema+json" の場合、空文字列を含むJSONポインタ構文に一致するフラグメント識別子は、JSONポインタフラグメント識別子として解釈する必要があります。
W3Cの フラグメント識別子のベストプラクティス [W3C.WD-fragid-best-practices-20121025] に従って、"application/schema+json" のプレーン名フラグメント識別子は、ローカルに名前が付けられたスキーマを参照するために予約されています。JSONポインタ構文に一致しないすべてのフラグメント識別子は、プレーン名フラグメント識別子として解釈する必要があります。
"application/schema+json" ドキュメント内でプレーン名フラグメント識別子を定義および参照することは、"$id" キーワード [id-keyword] セクションで指定されています。
インスタンスは、JSON [RFC7159] で定義されている有効なJSON値にすることができます。JSON Schemaは型に制限を課しません。JSON Schemaは、たとえばnullなど、任意のJSON値を記述できます。
JSON Schemaはプログラミング言語に依存せず、データモデルで記述されたすべての値の範囲をサポートします。ただし、一部の言語およびJSONパーサーは、JSONで記述できるすべての値の範囲をメモリ内で表現できない場合があることに注意してください。
一部のプログラミング言語とパーサーは、浮動小数点数と整数で異なる内部表現を使用します。
一貫性を保つために、整数JSON数値は小数部でエンコードしないでください。
実装は、JSON Schemaに追加のキーワードを定義できます。明示的な合意がない限り、スキーマの作成者は、これらの追加のキーワードがピア実装によってサポートされることを期待してはなりません。実装は、サポートしていないキーワードを無視する必要があります。
JSON Schemaの拡張機能の作成者は、"allOf" を使用して既存のメタスキーマを拡張する独自のメタスキーマを作成することをお勧めします。この拡張メタスキーマは、ツールが正しい動作に従えるように、"$schema" キーワードを使用して参照する必要があります。
メタスキーマの再帰的な性質は、JSONハイパースキーマメタスキーマで見られるように、拡張メタスキーマで再帰的なキーワードを再定義する必要があることに注意してください。
"$schema" キーワードは、JSON Schemaのバージョン識別子と、この特定のバージョン用に記述された任意のスキーマを記述するJSON Schema自体であるリソースの場所の両方として使用されます。
このキーワードの値は、スキームを含むURI [RFC3986] である必要があり、このURIは正規化する必要があります。現在のスキーマは、このURIで識別されるメタスキーマに対して有効である必要があります。
このURIが取得可能なリソースを識別する場合、そのリソースのメディアタイプは "application/schema+json" である必要があります。
"$schema" キーワードは、ルートスキーマで使用する必要があります。サブスキーマに表示してはなりません。
このプロパティの値は、他のドキュメントおよび他の関係者によって定義されています。JSON Schemaの実装は、妥当と見なされるJSON Schema語彙の現在および以前に公開されたドラフトのサポートを実装する必要があります。
広大なエコシステム内のスキーマを区別するために、スキーマは URI [RFC3986] によって識別され、URIを指定することで他のスキーマへの参照を埋め込むことができます。
RFC3986セクション5.1 [RFC3986] では、ドキュメントのデフォルトのベースURIを決定する方法を定義しています。
情報として、スキーマの初期ベースURIは、それが発見されたURI、または不明な場合は適切な代替URIです。
"$id" キーワードは、スキーマのURIと、スキーマ内の他のURI参照が解決されるベースURIを定義します。サブスキーマの "$id" は、その親スキーマのベースURIに対して解決されます。親が "$id" で明示的なベースを設定していない場合、ベースURIは、RFC 3986セクション5 [RFC3986] に従って決定された、ドキュメント全体のベースURIになります。
存在する場合、このキーワードの値は文字列である必要があり、有効な URI参照 [RFC3986] を表す必要があります。この値は正規化する必要があり、空のフラグメント <#> または空の文字列 <> にしないでください。
JSON Schemaドキュメントのルートスキーマには、絶対URI [RFC3986]（スキームを含みますが、フラグメントは含みません）またはこの絶対URIに空のフラグメントが含まれている "$id" キーワードを含める必要があります。
"$id" がベースURIを設定する場合、その "$id" を含むオブジェクトとそのすべてのサブスキーマは、その場所から始まるJSONポインタフラグメントを使用して識別できます。これは、ベースURIをさらに変更するサブスキーマにも当てはまります。したがって、単一のサブスキーマは、サブスキーマで宣言されたベースURIまたは親で宣言されたベースURIと、ベースを宣言するスキーマオブジェクトから識別されるサブスキーマへのパスを識別するJSONポインタフラグメントで構成される複数のURIからアクセスできます。この例は、セクション 8.2.4 に示されています。
JSONポインタフラグメントを使用するには、スキーマの構造に関する知識が必要です。再利用可能なスキーマを提供することを目的としたスキーマドキュメントを作成する場合、特定の構造的な場所に関連付けられていないプレーン名フラグメントを使用する方が望ましい場合があります。これにより、JSONポインタ参照を更新しなくても、サブスキーマを再配置できます。
このようなサブスキーマ識別子を指定するには、"$id" キーワードがプレーン名フラグメント（JSONポインタフラグメントではない）を持つURI参照に設定されます。この値は、フラグメントを指定する番号記号（"#"）で始まり、その後に文字（[A-Za-z]）、その後に任意の数の文字、数字（[0-9]）、ハイフン（"-"）、アンダースコア（"_"）、コロン（":"）、またはピリオド（"."）が続く必要があります。
「$id」内で、空白ではない、またはプレーンな名前の構文に従わないフラグメントを使用した場合の影響は未定義です。[CREF3]他のコンポーネントを含むフラグメントを含む「$id」URI参照はどのように解釈されるべきでしょうか？2つのケースがあります。他のコンポーネントが現在のベースURIと一致する場合と、ベースURIを変更する場合です。
以下のスキーマを検討してください。これは、「$id」を使用してルートスキーマを識別し、サブスキーマのベースURIを変更し、サブスキーマにプレーンな名前のフラグメントを割り当てる方法を示しています。
{
"$id": "http://example.com/root.json",
"definitions": {
"A": { "$id": "#foo" },
"B": {
"$id": "other.json",
"definitions": {
"X": { "$id": "#bar" },
"Y": { "$id": "t/inner.json" }
}
},
"C": {
"$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f"
}
}
}
以下のURIエンコードされたJSONポインタ[RFC6901]（ルートスキーマを基準とする）にあるスキーマは、以下のベースURIを持ち、上記のセクション5に従って、リストされた任意のURIで識別できます。
「$ref」キーワードはスキーマを参照するために使用され、自己参照を通じて再帰的な構造を検証する機能を提供します。
「$ref」プロパティを持つオブジェクトスキーマは、「$ref」参照として解釈する必要があります。「$ref」プロパティの値は、URI参照でなければなりません。現在のURIベースに対して解決されると、使用するスキーマのURIを識別します。「$ref」オブジェクトの他のすべてのプロパティは無視する必要があります。
URIはネットワークロケータではなく、単なる識別子です。ネットワークアドレス可能なURLの場合でも、スキーマをアドレスからダウンロードする必要はなく、実装はネットワークアドレス可能なURIに遭遇した場合にネットワーク操作を実行する必要があるとは想定すべきではありません。
スキーマがスキーマに対して無限ループに陥ってはなりません。たとえば、2つのスキーマ「#alice」と「#bob」の両方に、互いを参照する「allOf」プロパティがある場合、単純なバリデーターはインスタンスを検証しようとして無限の再帰ループに陥る可能性があります。スキーマはこのような無限の再帰ネストを使用すべきではありません。動作は未定義です。
リモートスキーマを識別するためにURIを使用することは、必ずしも何かがダウンロードされることを意味するのではなく、JSONスキーマの実装は、どのスキーマを使用するか、およびそれらを識別するURIを事前に理解しておく必要があります。
たとえば、どのスキーマをダウンロードするかを実行時まで知らない一般的なユーザーエージェントによってスキーマがダウンロードされる場合は、ハイパーメディアでの使用[ハイパーメディア]を参照してください。
実装は、バリデーターがスキーマに対して持つ信頼に応じて、任意のURIを任意のスキーマに関連付けたり、スキーマの「$id」で指定されたURIを自動的に関連付けたりできる必要があります。このようなURIとスキーマは、インスタンスを処理する前に実装に提供することも、セクション8.2.4に示すように、処理中にスキーマドキュメント内でメモし、関連付けを生成することもできます。
スキーマは複数のURIを持つ可能性があり（そしておそらくそうなるでしょう）、URIが複数のスキーマを識別する方法はありません。複数のスキーマが同じURIとして識別しようとする場合、バリデーターはエラー状態を発生させる必要があります。
スキーマは、JSONポインタや「$id」で直接指定されたURIなど、与えられた任意のURIで識別できます。いずれの場合も、「$ref」参照をデリファレンスするには、まずRFC 3986[RFC3986]に従って、現在のベースURIに対してその値をURI参照として解決する必要があります。
結果として得られるURIが現在のドキュメント内、または実装で利用可能になっている別のスキーマドキュメント内のスキーマを識別する場合は、そのスキーマを自動的に使用する必要があります。
たとえば、このスキーマを考えてみましょう。
{
"$id": "http://example.net/root.json",
"items": {
"type": "array",
"items": { "$ref": "#item" }
},
"definitions": {
"single": {
"$id": "#item",
"type": "object",
"additionalProperties": { "$ref": "other.json" }
}
}
}
実装が<#/definitions/single>スキーマに遭遇した場合、現在のベースURIに対して「$id」URI参照を解決して、<http://example.net/root.json#item>を形成します。
実装が<#/items>スキーマ内を調べると、<#item>参照に遭遇し、これを<http://example.net/root.json#item>に解決します。これは、同じドキュメントで定義されているため、自動的に使用できます。
実装が「other.json」への参照に遭遇すると、これを<http://example.net/other.json>に解決します。これはこのドキュメントでは定義されていません。その識別子を持つスキーマが実装に別途提供されている場合は、自動的に使用することもできます。[CREF4]参照されるスキーマが不明な場合、実装はどうすべきでしょうか？自動ネットワークデリファレンスが許可される状況はありますか？同一オリジンポリシー？ユーザー設定可能なオプション？ハイパースキーマによって記述された進化するAPIの場合、新しいスキーマがシステムに動的に追加されることが想定されるため、スキーマドキュメントの事前ロードを絶対的な要件とすることは実現可能ではありません。
このキーワードは、スキーマの作成者からスキーマの読者またはメンテナへのコメントのために予約されています。このキーワードの値は文字列でなければなりません。実装はこの文字列をエンドユーザーに表示してはなりません。スキーマを編集するためのツールは、このキーワードの表示と編集をサポートする必要があります。このキーワードの値は、スキーマを使用する開発者向けのデバッグまたはエラー出力で使用される場合があります。スキーマ語彙は、語彙キーワードを含む任意のオブジェクト内で「$comment」を許可する必要があります。実装は、語彙が特に禁止しない限り、「$comment」が許可されていると想定できます。語彙は、この仕様に記述されているものを超えて、「$comment」の影響を指定してはなりません。他のメディアタイプまたはプログラミング言語をapplication/schema+jsonとの間で変換するツールは、そのメディアタイプまたはプログラミング言語のネイティブコメントを「$comment」値との間で変換することを選択できます。ネイティブコメントと「$comment」プロパティの両方が存在する場合のこのような変換の動作は、実装に依存します。実装は、「$comment」を不明な拡張キーワードと同じように扱う必要があります。処理中の任意の時点で「$comment」値を削除できます。特に、これにより、デプロイされたスキーマのサイズが懸念される場合にスキーマを短縮できます。実装は、「$comment」プロパティの有無、または内容に基づいて他のアクションを実行してはなりません。
JSONは、自動化されたAPIおよびロボット用にHTTPサーバーで広く採用されています。このセクションでは、メディアタイプとWebリンク[RFC8288]をサポートするプロトコルで使用する場合に、JSONドキュメントの処理をよりRESTfulな方法で強化する方法について説明します。
Linked Data Protocol 1.0、セクション8.1[W3C.REC-ldp-20150226]で定義されているように、スキーマによって記述されたインスタンスが「describedby」リンク関係を使用してダウンロード可能なJSONスキーマへのリンクを提供することを推奨します。
HTTPでは、このようなリンクはLinkヘッダー[RFC8288]を使用して任意のレスポンスに添付できます。このようなヘッダーの例は次のようになります。
Link: <http://example.com/my-hyper-schema#>; rel="describedby"
メディアタイプは、「schema」メディアタイプパラメータを許可する場合があります。これにより、HTTPサーバーはスキーマに基づいてContent-Typeネゴシエーションを実行できます。メディアタイプパラメータは、URIの空白区切りのリストである必要があります（つまり、相対参照は無効です）。
メディアタイプapplication/schema-instance+jsonを使用する場合、「schema」パラメータを指定する必要があります。
スキーマURIは不透明であり、自動的にデリファレンスされるべきではありません。実装が提供されたスキーマのセマンティクスを理解していない場合、実装は代わりに「describedby」リンク（存在する場合）をたどることができます。これらはスキーマの処理方法に関する情報を提供する場合があります。「schema」は必ずしもネットワークの場所を指しているわけではないため、ダウンロード可能なスキーマへのリンクには「describedby」関係が使用されます。ただし、簡単にするために、スキーマの作成者は、可能であれば、これらのURIが同じリソースを指すようにする必要があります。
HTTPでは、メディアタイプパラメータはContent-Typeヘッダー内で送信されます。
Content-Type: application/json;
schema="http://example.com/my-hyper-schema#"
複数のスキーマは空白で区切られます。
Content-Type: application/json;
schema="http://example.com/alice http://example.com/bob"
[CREF5]この段落では、「schema」リンク関係を登録できると仮定しています。代わりに、当面は「tag:json-schema.org,2017:schema」のようなものを指定する必要がありますか？HTTPは、Linkで「schema」を送信することもできますが、これがメディアタイプパラメータを完全に置き換える場合、メディアタイプのセマンティクスとContent-Typeネゴシエーションに影響を与える可能性があります。
Link: </alice>;rel="schema", </bob>;rel="schema"
ネットワーク上のハイパーメディアシステムで使用する場合、スキーマを配布するためのプロトコルとして、HTTP[RFC7231]が頻繁に選択されます。クライアントが不適切な動作をすると、スキーマを長期間キャッシュできる場合に、必要以上に頻繁にネットワーク経由でスキーマをプルした場合に、サーバーのメンテナに問題を引き起こす可能性があります。
HTTPサーバーは、JSONスキーマに長寿命のキャッシュヘッダーを設定する必要があります。HTTPクライアントは、キャッシュヘッダーを監視し、鮮度期間内にドキュメントを再リクエストしないようにする必要があります。分散システムは、共有キャッシュやキャッシュプロキシを使用する必要があります。
User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
クライアントは、JSONスキーマの実装またはソフトウェア製品に固有のUser-Agentヘッダーを設定または先頭に追加する必要があります。記号は重要度の高い順にリストされているため、JSONスキーマライブラリの名前/バージョンは、より一般的なHTTPライブラリ名（存在する場合）よりも優先される必要があります。例：
クライアントは、サーバーオペレータが潜在的に誤動作しているスクリプトの所有者に連絡できるように、「From」ヘッダーを使用してリクエストを実行できる必要があります。
スキーマとインスタンスはどちらもJSON値です。そのため、RFC 7159[RFC7159]で定義されているすべてのセキュリティに関する考慮事項が適用されます。
インスタンスとスキーマはどちらも、多くの場合、信頼されていないサードパーティによって作成され、公開インターネットサーバーにデプロイされます。バリデーターは、スキーマに対する解析と検証が過度のシステムリソースを消費しないように注意する必要があります。バリデーターは無限ループに陥ってはなりません。
サーバーは、悪意のあるパーティが既存のスキーマの機能を、既存または非常によく似た「$id」を持つスキーマをアップロードすることによって変更できないようにする必要があります。
個々のJSONスキーマ語彙には、独自のセキュリティに関する考慮事項もある可能性があります。詳細については、それぞれの仕様を参照してください。
スキーマの作成者は、"$comment" の内容に注意する必要があります。悪意のある実装は、仕様に違反してエンドユーザーに "$comment" の内容を表示したり、そのような動作が期待される場合にそれらを削除しなかったりする可能性があります。
悪意のあるスキーマ作成者は、"$comment" の中に実行可能なコードやその他の危険な素材を配置する可能性があります。実装は、"$comment" の内容を解析したり、それに基づいてアクションを実行したりしてはなりません。
JSON Schema に提案されている MIME メディアタイプは、次のように定義されます。
JSON Schema固有のメディアタイプを必要とする JSON Schemaインスタンスに提案されている MIME メディアタイプは、次のように定義されます。
| [RFC2119] | Bradner, S., "RFCで要求レベルを示すためのキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月。 |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月。 |
| [RFC6839] | Hansen, T. and A. Melnikov, "追加のメディアタイプ構造化構文サフィックス", RFC 6839, DOI 10.17487/RFC6839, 2013年1月。 |
| [RFC6901] | Bryan, P., Zyp, K. and M. Nottingham, "JavaScript Object Notation (JSON) ポインター", RFC 6901, DOI 10.17487/RFC6901, 2013年4月。 |
| [RFC7159] | Bray, T., "JavaScript Object Notation (JSON) データ交換形式", RFC 7159, DOI 10.17487/RFC7159, 2014年3月。 |
| [W3C.REC-ldp-20150226] | Speicher, S., Arwe, J. and A. Malhotra, "Linked Data Platform 1.0", World Wide Web Consortium Recommendation REC-ldp-20150226, 2015年2月。 |
| [RFC7049] | Bormann, C. and P. Hoffman, "簡潔なバイナリオブジェクト表現 (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 2013年10月。 |
| [RFC7231] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): セマンティクスとコンテンツ", RFC 7231, DOI 10.17487/RFC7231, 2014年6月。 |
| [RFC8288] | Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, 2017年10月。 |
| [W3C.WD-fragid-best-practices-20121025] | Tennison, J., "フラグメント識別子とメディアタイプ定義のベストプラクティス", World Wide Web Consortium LastCall WD-fragid-best-practices-20121025, 2012年10月。 |
| [json-schema-validation] | Wright, A., Andrews, H. and G. Luff, "JSON Schema の検証: JSON の構造検証のためのボキャブラリー", Internet-Draft draft-handrews-json-schema-validation-01, 2017年11月。 |
| [json-hyper-schema] | Andrews, H. and A. Wright, "JSON Hyper-Schema: JSON のハイパーメディア注釈のためのボキャブラリー", Internet-Draft draft-handrews-json-schema-hyperschema-01, 2017年11月。 |
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に感謝いたします。
[CREF6]このセクションは、インターネットドラフトの状態を離れる前に削除されます。