| インターネット技術特別調査委員会 | A. ライト (編) |
| インターネットドラフト | |
| 予定ステータス: 情報提供 | H. アンドリュース (編) |
| 有効期限: 2018年9月20日 | Cloudflare, Inc. |
| 2018年3月19日 |
JSON Schema: JSONドキュメントを記述するためのメディアタイプ
draft-handrews-json-schema-01
JSON Schema は、JSONデータの構造を記述するためのJSONベースのフォーマットであるメディアタイプ "application/schema+json" を定義します。JSON Schemaは、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 法的規定のセクション 4.e に記載されている簡略化された BSD ライセンステキストを含める必要があり、簡略化された BSD ライセンスに記載されているように保証なしで提供されます。
JSON Schemaは、JSONデータの構造を定義するためのJSONメディアタイプです。JSON Schemaは、JSONデータの検証、ドキュメント、ハイパーリンクナビゲーション、およびインタラクション制御を定義することを目的としています。
この仕様は、参照による別のJSONスキーマのポイント、JSONスキーマ参照の参照解除、および使用されている語彙の指定など、JSONスキーマのコア用語とメカニズムを定義します。
他の仕様では、検証、リンク、アノテーション、ナビゲーション、およびインタラクションに関するアサーションを実行する語彙を定義しています。
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [RFC2119] で説明されているように解釈されるものとします。
このドキュメントの「JSON」、「JSONテキスト」、「JSON値」、「メンバー」、「要素」、「オブジェクト」、「配列」、「数値」、「文字列」、「ブール値」、「真」、「偽」、および「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 Schemaの語彙は、独自の拡張型システムを自由に定義できることに注意してください。これはここで定義されているコアデータモデルの型と混同すべきではありません。例として、「integer」は語彙がキーワードの値として定義するのに妥当な型ですが、データモデルは整数と他の数値を区別しません。
JSON Schemaは、「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つだけです。つまり、複数の語彙を使用するには、それらすべてを包含するメタスキーマを作成する必要があります。ハイパースキーマメタスキーマは、検証語彙とハイパーメディア語彙を包含している例です。
ルートスキーマは、問題のJSONドキュメント全体を構成するスキーマです。
一部のキーワードはスキーマ自体を取り込み、JSON Schemaをネストできるようにします
{
"title": "root",
"items": {
"title": "array item"
}
}
このドキュメント例では、「配列項目」というタイトルのスキーマはサブスキーマであり、「ルート」というタイトルのスキーマはルートスキーマです。
ルートスキーマと同様に、サブスキーマはオブジェクトまたはブール値のいずれかです。
[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 Hyper-Schemaメタスキーマで見られるように、拡張メタスキーマで再帰的なキーワードを再定義する必要があることに注意してください。
「$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]（スキームを含み、フラグメントを含まない）を持つ "$id" キーワード、または空のフラグメントを持つこの絶対URIをSHOULD含める必要があります。
"$id"がベースURIを設定する場合、その "$id" を含むオブジェクトとそのすべてのサブスキーマは、その場所から始まるJSONポインタフラグメントを使用して識別できます。これは、ベースURIをさらに変更するサブスキーマにも当てはまります。したがって、単一のサブスキーマは、サブスキーマまたは親で宣言されたベースURIと、ベースを宣言するスキーマオブジェクトから識別されるサブスキーマへのパスを識別するJSONポインタフラグメントで構成される複数のURIでアクセスできる場合があります。この例は、8.2.4節に示されています。
JSONポインタフラグメントを使用するには、スキーマの構造に関する知識が必要です。再利用可能なスキーマを提供する目的でスキーマドキュメントを作成する場合、特定の構造的な場所に結び付けられていないプレーンな名前フラグメントを使用することをお勧めします。これにより、JSONポインタ参照を更新することなく、サブスキーマを再配置できます。
このようなサブスキーマ識別子を指定するには、"$id"キーワードをプレーンな名前フラグメント（JSONポインタフラグメントではない）を持つURI参照に設定します。この値は、フラグメントを指定する番号記号（"#"）で始まり、その後に文字（[A-Za-z]）、続いて任意の数の文字、数字（[0-9]）、ハイフン（"-"）、アンダースコア（"_"）、コロン（":"）、またはピリオド（"."）が続く必要があります。
ブランクではないか、プレーンな名前の構文に従わないフラグメントを "$id" で使用した場合の効果は未定義です。[CREF3]他のコンポーネントを含むフラグメントを持つ "$id" URI参照は、どのように解釈する必要がありますか？ 他のコンポーネントが現在のベースURIと一致する場合と、ベースURIを変更する場合の2つのケースがあります。
ルートスキーマの識別、サブスキーマのベースURIの変更、およびサブスキーマへのプレーンな名前フラグメントの割り当てに "$id" が使用されている次のスキーマを検討してください。
{
"$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 Schema実装は、どのスキーマを使用するか、それらを識別するURIを事前に理解する必要があります。
たとえば、どのスキーマをダウンロードするかを実行時までわからない汎用ユーザーエージェントによってスキーマがダウンロードされる場合は、ハイパーメディアでの使用 [hypermedia]を参照してください。
実装は、検証者がスキーマを信頼している度合いに応じて、任意のURIを任意のスキーマに関連付けたり、スキーマの "$id" で指定されたURIを自動的に関連付けたりできる必要があります。このようなURIとスキーマは、インスタンスを処理する前に実装に提供されるか、処理中にスキーマドキュメント内でメモされ、8.2.4節に示すような関連付けを生成できます。
スキーマは、複数のURIを持つことがありますが（そしておそらく持つでしょう）、1つの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]参照されているスキーマが不明な場合、実装はどうする必要がありますか？ 自動的なネットワーク逆参照が許可される状況はありますか？ 同一生成元ポリシー？ ユーザーが構成可能なオプション？ Hyper-Schemaで記述された進化するAPIの場合、新しいスキーマがシステムに動的に追加されることが想定されるため、スキーマドキュメントを事前にロードするという絶対的な要件を課すことは実現可能ではありません。
このキーワードは、スキーマの作成者からスキーマの読者または保守者へのコメントのために予約されています。このキーワードの値は文字列である必要があります。実装は、この文字列をエンドユーザーに提示してはなりません。スキーマを編集するためのツールは、このキーワードの表示と編集をサポートする必要があります。このキーワードの値は、スキーマを使用する開発者向けのデバッグまたはエラー出力で使用できます。スキーマの語彙は、語彙キーワードを含む任意のオブジェクト内で "$comment" を許可する必要があります。実装は、語彙が明確に禁止しない限り、"$comment" が許可されていると想定できます。語彙は、この仕様で説明されていること以外に "$comment" の効果を指定してはなりません。他のメディアタイプまたはプログラミング言語をアプリケーション/スキーマ+jsonとの間で変換するツールは、そのメディアタイプまたはプログラミング言語のネイティブコメントを "$comment" 値との間で変換することを選択できます。ネイティブコメントと "$comment" プロパティの両方が存在する場合のこのような変換の動作は、実装に依存します。実装は、"$comment" を不明な拡張キーワードと同じように扱う必要があります。これらは、処理中の任意の時点で "$comment" 値を削除する場合があります。特に、これにより、デプロイされたスキーマのサイズが懸念される場合にスキーマを短縮できます。実装は、"$comment" プロパティの存在、不在、または内容に基づいて他のアクションを実行してはなりません。
JSONは、自動化されたAPIとロボットのためにHTTPサーバーによって広く採用されています。このセクションでは、メディアタイプとWebリンク [RFC8288]をサポートするプロトコルで使用する場合に、よりRESTfulな方法でJSONドキュメントの処理を強化する方法について説明します。
スキーマによって記述されたインスタンスは、Linked Data Protocol 1.0、セクション8.1 [W3C.REC-ldp-20150226]で定義されているように、リンク関係 "describedby" を使用して、ダウンロード可能なJSON Schemaへのリンクを提供することを推奨します。
HTTPでは、このようなリンクは、Linkヘッダー [RFC8288]を使用して、任意応答にアタッチできます。そのようなヘッダーの例は次のとおりです。
Link: <http://example.com/my-hyper-schema#>; rel="describedby"
メディアタイプは、スキーマに基づいてHTTPサーバーがContent-Typeネゴシエーションを実行できるようにする "schema" メディアタイプパラメーターを許可する場合があります。メディアタイプパラメーターは、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 Schemaに長期間キャッシュヘッダーを設定する必要があります。HTTPクライアントは、キャッシュヘッダーを観察し、その有効期間内にドキュメントを再リクエストしないでください。分散システムは、共有キャッシュまたはキャッシュプロキシを使用する必要があります。
User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0
クライアントは、JSON Schema実装またはソフトウェア製品に固有のUser-Agentヘッダーを設定または先頭に追加する必要があります。記号は重要度の高い順にリストされているため、JSON Schemaライブラリ名/バージョンは、より一般的なHTTPライブラリ名（存在する場合）よりも前に付ける必要があります。例えば
クライアントは、サーバーオペレーターが誤動作している可能性のあるスクリプトの所有者に連絡できるように、"From" ヘッダー付きでリクエストを送信できる必要があります。
スキーマとインスタンスはどちらもJSON値です。したがって、RFC 7159 [RFC7159] で定義されているすべてのセキュリティに関する考慮事項が適用されます。
インスタンスとスキーマはどちらも、信頼できない第三者によって作成され、公共のインターネットサーバーにデプロイされることがよくあります。バリデーターは、スキーマに対する解析と検証が過剰なシステムリソースを消費しないように注意する必要があります。バリデーターは、無限ループに陥ってはなりません（MUST NOT）。
サーバーは、悪意のある第三者が既存の「$id」を持つスキーマ、または非常に類似した「$id」を持つスキーマをアップロードすることにより、既存のスキーマの機能を変更できないようにする必要があります（MUST）。
個々のJSON Schema語彙には、独自のセキュリティに関する考慮事項も存在します。詳細については、それぞれの仕様を参照してください。
スキーマ作成者は、「$comment」の内容に注意する必要があります。悪意のある実装は、仕様に違反してエンドユーザーに表示したり、そのような動作が期待される場合に削除に失敗する可能性があります。
悪意のあるスキーマ作成者は、「$comment」内に実行可能コードやその他の危険な素材を配置する可能性があります。実装は、「$comment」の内容に基づいて解析したり、アクションを実行したりしてはなりません（MUST NOT）。
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): 一般的な構文", 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ハイパースキーマ: 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]このセクションは、インターネットドラフトのステータスを離れる前に削除されます。