Internet Engineering Task Force A. ライト、編
インターネットドラフト
意図されたステータス:情報提供 H. アンドリュース、編
期限:2018年9月20日 Cloudflare, Inc.
G. ラフ
2018年3月19日

JSONスキーマ検証:JSONの構造的検証のための語彙
draft-handrews-json-schema-validation-01

概要

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の規定に完全に準拠して提出されています。

インターネットドラフトは、Internet Engineering Task Force(IETF)の作業ドキュメントです。他のグループもインターネットドラフトとして作業ドキュメントを配布する場合があることに注意してください。現在のインターネットドラフトのリストは、http://datatracker.ietf.org/drafts/current/ にあります。

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

このインターネットドラフトは、2018年9月20日に期限切れになります。

著作権表示

Copyright(c)2018 IETF Trustおよびドキュメントの作成者として特定された個人。All rights reserved。

このドキュメントは、BCP 78およびこのドキュメントの発行日に有効なIETF TrustのIETFドキュメントに関する法的規定(http://trustee.ietf.org/license-info)の対象となります。このドキュメントに関するあなたの権利と制限を説明しているので、これらのドキュメントを注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trustの法的規定のセクション4.eに記載されている簡略化されたBSDライセンステキストを含める必要があり、簡略化されたBSDライセンスに記載されているように保証なしで提供されます。


目次

1. はじめに

JSONスキーマは、特定のJSONドキュメント(インスタンス)が特定の数の基準を満たすことを要求するために使用できます。これらの基準は、この仕様で説明されているキーワードを使用して表明されます。さらに、インタラクティブなユーザーインターフェースインスタンスの生成を支援するために、一連のキーワードも定義されています。

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

2. 規約と用語

このドキュメントで使用されているキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [RFC2119]で説明されているように解釈されるものとします。

この仕様では、「コンテナインスタンス」という用語は、配列インスタンスとオブジェクトインスタンスの両方を指すために使用します。「子インスタンス」という用語は、配列要素またはオブジェクトメンバー値を指すために使用します。

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

3. 概要

JSONスキーマ検証は、インスタンス内の位置にスキーマを適用し、各位置でのデータの構造に関する制約を表明します。表明されたすべての制約を満たすインスタンスの位置には、記述的なメタデータや使用上のヒントなど、アサーション情報以外の情報を含むキーワードが注釈されます。インスタンス内のすべての位置が表明されたすべての制約を満たしている場合、インスタンスはスキーマに対して有効であると言われます。

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

3.1. 適用性

検証は、ルートスキーマを完全なインスタンスドキュメントに適用することから始まります。そこから、さまざまなキーワードを使用して、追加のサブスキーマを現在の場所または子の場所に適用するかどうかを判断します。これらのキーワードは、サブスキーマのアサーション結果がどのように変更および/または結合されるかも定義します。そのようなキーワードは、それ自体で条件を表明するものではありません。むしろ、アサーションがどのように適用および評価されるかを制御します。

この仕様のブール論理 [logic]および条件付き [conditional]セクションのキーワードは、親スキーマと同じ場所にサブスキーマを適用します。前者のグループは、サブスキーマのアサーション結果に対するブール演算を定義し、後者のグループは1つのサブスキーマを評価し、そのアサーション結果を使用して、他の2つのサブスキーマのどちらを適用するかを決定します。

いくつかのキーワードは、配列項目、オブジェクトプロパティ値、およびオブジェクトプロパティ名にどのサブスキーマが適用されるかを決定します。それらは、「items」、「additionalItems」、「contains」、「properties」、「patternProperties」、「additionalProperties」、および「propertyNames」です。「contains」キーワードは、そのサブスキーマが少なくとも1つの子インスタンスに対して有効であることを要求するだけですが、他のキーワードは、すべてのサブスキーマがそれらが適用されるすべての子インスタンスに対して有効であることを要求します。

3.1.1. キーワードの独立性

検証キーワードは通常、互いの結果に影響を与えることなく、独立して動作します。

スキーマ作成者の利便性のために、サブスキーマの適用性を制御するキーワードの中には例外があります。

3.2. アサーション

検証は、アサーションをチェックするプロセスです。各アサーションは、インスタンスが正常に検証されるために満たす必要のある制約を追加します。

存在しないアサーションキーワードは、検証を制限することはありません。場合によっては、このno-opの動作は、特定の値を持つ既存のキーワードと同じであり、これらの値は既知の場合に記録されます。

一般 [general]数値 [numeric]、および文字列 [string]セクションのすべてのキーワードは、アサーションであり、「minItems」、「maxItems」、「uniqueItems」、「minProperties」、「maxProperties」、および「required」も同様です。さらに、「dependencies」は条件付きキーワードとアサーションキーワードの組み合わせの略語です。

「format」、「contentType」、および「contentEncoding」キーワードもアサーションとして実装できますが、その機能はこの仕様のオプション部分であり、キーワードは追加のアサーション以外の情報も伝えます。

3.2.1. アサーションとインスタンスプリミティブ型

ほとんどの検証アサーションは、特定のプリミティブ型内の値のみを制約します。インスタンスの型がキーワードのターゲットである型でない場合、インスタンスはアサーションに準拠していると見なされます。

たとえば、「maxLength」キーワードは、特定の文字列(長すぎるもの)が有効になることを制限するだけです。インスタンスが数値、ブール値、null、配列、またはオブジェクトの場合、このアサーションに対して有効です。

3.3. 注釈

アサーションに加えて、この仕様は、JSONインスタンスに役立つ情報を注釈するために使用できるメタデータキーワードの小さな語彙を提供します。セクション7およびセクション8のキーワードは、インスタンスデータに追加の使用ガイダンスを伝えるため、オプションのアサーションであるだけでなく、注釈としても役立ちます。

インスタンスの特定の場所に適用可能で、そのインスタンスの場所が有効なスキーマは、その注釈をインスタンス内のその場所に添付します。多くのサブスキーマが1つの場所に対して適用可能である可能性があるため、注釈キーワードは、異なる値を持つキーワードの複数の適用可能な出現の異常な処理を指定する必要があります。デフォルトの動作は、すべての値を収集することだけです。

追加の語彙は、インスタンスに独自のアノテーションを適用するために、このメカニズムを使用するべきです(SHOULD)。

3.3.1. アノテーションと検証結果

インスタンスがスキーマオブジェクト、およびそのスキーマオブジェクトのすべての親スキーマに対して有効な場合、常にアノテーションが収集されます。

特に、「not」内に含まれるサブスキーマ内のアノテーションは、深さに関わらず、間にいくつ「not」サブスキーマがあっても、無視しなければなりません(MUST)。インスタンスが「not」サブスキーマに対して有効である場合、定義上、それは「not」を含むスキーマに対して有効ではないため、「not」サブスキーマのアノテーションは使用されません。

同様に、「oneOf」、「anyOf」、「then」、または「else」の失敗したブランチ内のアノテーションは、インスタンスが完全なスキーマドキュメントに対して正常に検証された場合でも、無視しなければなりません(MUST)。

3.3.2. アノテーションとショートサーキット検証

アノテーションキーワードは、すべての可能なサブインスタンスに適用しなければなりません(MUST)。アサーションの評価のみが必要な場合にショートサーキットできたとしてもです。たとえば、「contains」キーワードは、少なくとも1つの配列項目が有効であることが証明されるまで、アサーションのチェックのみが必要となります。ただし、アノテーションを扱う場合、アノテーションを関連付ける必要のあるすべての項目を決定するために、配列内のすべての項目を評価する必要があります。

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

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

ヌル文字(\u0000)はJSON文字列で有効であることに注意してください。検証対象のインスタンスには、基盤となるプログラミング言語がそのようなデータを処理できるかどうかにかかわらず、この文字を含む文字列値が含まれる場合があります。

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

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

4.3. 正規表現

2つの検証キーワード、「pattern」と「patternProperties」は、制約を表現するために正規表現を使用し、「format」キーワードの「regex」値は、インスタンス値を正規表現に制約します。これらの正規表現は、ECMA 262 [ecma262]正規表現方言に従って有効であるべきです(SHOULD)。

さらに、正規表現構造のサポートには大きなばらつきがあるため、スキーマの作成者は、以下の正規表現トークンに制限するべきです(SHOULD)。

最後に、実装は正規表現が先頭または末尾のどちらにもアンカーされていると見なしてはなりません(MUST NOT)。たとえば、パターン "es" は "expression" に一致することを意味します。

5. メタスキーマ

JSON Schema Validationの現在のURIは、<https://json-schema.dokyumento.jp/draft-07/schema#>です。

6. 検証キーワード

スキーマ内の検証キーワードは、インスタンスの検証を成功させるための要件を課します。

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

6.1.1. type

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

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

インスタンスは、このキーワードにリストされているいずれかのセットに含まれている場合にのみ検証されます。

6.1.2. enum

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

インスタンスの値がこのキーワードの配列値の要素の1つと等しい場合、このキーワードに対して正常に検証されます。

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

6.1.3. const

このキーワードの値は、nullを含む任意の型である可能性があります(MAY)。

インスタンスの値がキーワードの値と等しい場合、このキーワードに対して正常に検証されます。

6.2. 数値インスタンス(numberとinteger)の検証キーワード

6.2.1. multipleOf

"multipleOf"の値は、0より大きい数値でなければなりません(MUST)。

数値インスタンスは、このキーワードの値による除算の結果が整数になる場合にのみ有効です。

6.2.2. maximum

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

インスタンスが数値の場合、このキーワードはインスタンスが"maximum"以下の場合にのみ検証されます。

6.2.3. exclusiveMaximum

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

インスタンスが数値の場合、インスタンスの値が"exclusiveMaximum"よりも厳密に小さい(等しくない)場合にのみ有効です。

6.2.4. minimum

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

インスタンスが数値の場合、このキーワードはインスタンスが"minimum"以上の場合にのみ検証されます。

6.2.5. exclusiveMinimum

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

インスタンスが数値の場合、インスタンスの値が"exclusiveMinimum"よりも厳密に大きい(等しくない)場合にのみ有効です。

6.3. 文字列の検証キーワード

6.3.1. maxLength

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

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

文字列インスタンスの長さは、RFC 7159 [RFC7159]で定義されている文字数として定義されます。

6.3.2. minLength

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

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

文字列インスタンスの長さは、RFC 7159 [RFC7159]で定義されている文字数として定義されます。

このキーワードを省略すると、値が0の場合と同じ動作になります。

6.3.3. pattern

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

正規表現がインスタンスに正常に一致した場合、文字列インスタンスは有効と見なされます。注意:正規表現は暗黙的にアンカーされていません。

6.4. 配列の検証キーワード

6.4.1. items

"items"の値は、有効なJSON Schemaまたは有効なJSON Schemaの配列のいずれかでなければなりません(MUST)。

このキーワードは、配列の子インスタンスがどのように検証されるかを決定し、直接的には即時のインスタンス自体を検証しません。

"items"がスキーマの場合、配列内のすべての要素がそのスキーマに対して正常に検証されると、検証は成功します。

"items"がスキーマの配列の場合、インスタンスの各要素が同じ位置にあるスキーマ(存在する場合)に対して検証されると、検証は成功します。

このキーワードを省略すると、空のスキーマと同じ動作になります。

6.4.2. additionalItems

"additionalItems"の値は、有効なJSON Schemaでなければなりません(MUST)。

このキーワードは、配列の子インスタンスがどのように検証されるかを決定し、直接的には即時のインスタンス自体を検証しません。

"items"がスキーマの配列の場合、"items"のサイズよりも大きい位置にあるすべてのインスタンス要素が"additionalItems"に対して検証されると、検証は成功します。

それ以外の場合、"additionalItems"は無視しなければなりません(MUST)。"items"スキーマ(おそらく空のスキーマのデフォルト値)がすべての要素に適用されるためです。

このキーワードを省略すると、空のスキーマと同じ動作になります。

6.4.3. maxItems

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

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

6.4.4. minItems

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

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

このキーワードを省略すると、値が0の場合と同じ動作になります。

6.4.5. uniqueItems

このキーワードの値はブール値でなければなりません(MUST)。

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

このキーワードを省略すると、値がfalseの場合と同じ動作になります。

6.4.6. contains

このキーワードの値は、有効なJSON Schemaでなければなりません(MUST)。

配列インスタンスは、その要素の少なくとも1つが指定されたスキーマに対して有効な場合、"contains"に対して有効です。

6.5. オブジェクトの検証キーワード

6.5.1. maxProperties

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

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

6.5.2. minProperties

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

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

このキーワードを省略すると、値が0の場合と同じ動作になります。

6.5.3. required

このキーワードの値は配列でなければなりません(MUST)。この配列の要素は、存在する場合、文字列でなければならず(MUST)、一意でなければなりません(MUST)。

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

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

6.5.4. properties

"properties"の値はオブジェクトでなければなりません(MUST)。このオブジェクトの各値は、有効なJSON Schemaでなければなりません(MUST)。

このキーワードは、オブジェクトの子インスタンスがどのように検証されるかを決定し、直接的には即時のインスタンス自体を検証しません。

インスタンスとこのキーワードの値の両方に現れる各名前について、その名前の子インスタンスが対応するスキーマに対して正常に検証された場合、検証は成功します。

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

6.5.5. patternProperties

"patternProperties" の値はオブジェクトでなければなりません。このオブジェクトの各プロパティ名は、ECMA 262 正規表現の方言に従った有効な正規表現である必要があります。このオブジェクトの各プロパティの値は、有効な JSON スキーマでなければなりません。

このキーワードは、オブジェクトに対する子インスタンスの検証方法を決定するものであり、直接的に直近のインスタンス自体を検証するものではありません。このキーワードに対するプリミティブなインスタンス型の検証は、常に成功します。

このキーワードの値のプロパティ名として現れる正規表現に一致する各インスタンス名について、その名前の子インスタンスが、一致する各正規表現に対応する各スキーマに対して正常に検証された場合、検証は成功します。

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

6.5.6. additionalProperties

"additionalProperties" の値は、有効な JSON スキーマでなければなりません。

このキーワードは、オブジェクトの子インスタンスがどのように検証されるかを決定し、直接的には即時のインスタンス自体を検証しません。

"additionalProperties" を使用した検証は、"properties" の名前にも、"patternProperties" の正規表現にも一致しないインスタンス名の子の値にのみ適用されます。

そのようなすべてのプロパティについて、子インスタンスが "additionalProperties" スキーマに対して検証に成功した場合、検証は成功します。

このキーワードを省略すると、空のスキーマと同じ動作になります。

6.5.7. dependencies

[CREF1]このキーワードは、サブスキーマではなくプロパティ名の配列を使用するバリエーションに新しい名前を与えることで、2つに分割することができます。二重の動作は紛らわしく、実装が比較的困難です。前のドラフトでは、このキーワードを完全に削除するか、その形式の1つを削除することを提案しましたが、維持を支持するフィードバックを受けました。詳細な議論については、<https://github.com/json-schema-org/json-schema-spec/issues>にあるissue #442と#528を参照してください。さらなるフィードバックをお待ちしています。

このキーワードは、インスタンスがオブジェクトであり、特定のプロパティが含まれている場合に評価されるルールを指定します。

このキーワードの値はオブジェクトでなければなりません。各プロパティは依存関係を指定します。各依存関係の値は、配列または有効な JSON スキーマでなければなりません。

依存関係の値がサブスキーマであり、依存関係キーがインスタンスのプロパティである場合、インスタンス全体が依存関係の値に対して検証に成功する必要があります。

依存関係の値が配列の場合、配列の各要素は(もしあれば)文字列でなければならず、一意でなければなりません。依存関係キーがインスタンスのプロパティである場合、依存関係の値の各項目は、インスタンスに存在するプロパティでなければなりません。

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

6.5.8. propertyNames

"propertyNames" の値は、有効な JSON スキーマでなければなりません。

インスタンスがオブジェクトの場合、このキーワードは、インスタンス内のすべてのプロパティ名が指定されたスキーマに対して検証に成功した場合に検証されます。スキーマがテストするプロパティ名は常に文字列であることに注意してください。

このキーワードを省略すると、空のスキーマと同じ動作になります。

6.6. サブスキーマを条件付きで適用するためのキーワード

これらのキーワードは、別のサブスキーマの結果に基づいてサブスキーマの条件付き適用を実装するために連携して動作します。

これらのキーワードは、サブスキーマの境界を越えて相互作用してはなりません。言い換えれば、"allOf" の1つのブランチにある "if" は、別のブランチにある "then" や "else" に影響を与えてはなりません。

これらのキーワードが存在しない場合のデフォルトの動作はありません。特に、空のスキーマが存在する場合と同じように扱われるべきではありません。また、"if" が存在しない場合、"then" と "else" の両方が完全に無視される必要があります。

6.6.1. if

このキーワードの値は、有効な JSON スキーマでなければなりません。

このキーワードのサブスキーマの検証結果は、全体的な検証結果に直接的な影響を与えません。むしろ、"then" または "else" キーワードのどちらが評価されるかを制御します。

このキーワードのサブスキーマに対して正常に検証されるインスタンスは、存在する場合は、"then" キーワードのサブスキーマ値に対しても有効である必要があります。

このキーワードのサブスキーマに対して検証に失敗するインスタンスは、存在する場合は、"else" キーワードのサブスキーマ値に対しても有効である必要があります。

アノテーション [annotations] が収集されている場合、このキーワードのサブスキーマから通常の方法で収集されます。これには、"then" または "else" のいずれもなしでキーワードが存在する場合も含まれます。

6.6.2. then

このキーワードの値は、有効な JSON スキーマでなければなりません。

"if" が存在し、インスタンスがそのサブスキーマに対して正常に検証された場合、インスタンスがこのキーワードのサブスキーマに対しても正常に検証された場合に、このキーワードに対する検証は成功します。

"if" が存在しない場合、またはインスタンスがそのサブスキーマに対して検証に失敗した場合、このキーワードは効果がありません。実装は、検証またはアノテーション収集の目的で、このような場合にこのキーワードに対してインスタンスを評価してはなりません。

6.6.3. else

このキーワードの値は、有効な JSON スキーマでなければなりません。

"if" が存在し、インスタンスがそのサブスキーマに対して検証に失敗した場合、インスタンスがこのキーワードのサブスキーマに対して正常に検証された場合に、このキーワードに対する検証は成功します。

"if" が存在しない場合、またはインスタンスがそのサブスキーマに対して正常に検証された場合、このキーワードは効果がありません。実装は、検証またはアノテーション収集の目的で、このような場合にこのキーワードに対してインスタンスを評価してはなりません。

6.7. ブール論理でサブスキーマを適用するためのキーワード

6.7.1. allOf

このキーワードの値は、空ではない配列でなければなりません。配列の各項目は、有効な JSON スキーマでなければなりません。

インスタンスは、このキーワードの値によって定義されたすべてのスキーマに対して正常に検証された場合、このキーワードに対して正常に検証されます。

6.7.2. anyOf

このキーワードの値は、空ではない配列でなければなりません。配列の各項目は、有効な JSON スキーマでなければなりません。

インスタンスは、このキーワードの値によって定義された少なくとも1つのスキーマに対して正常に検証された場合、このキーワードに対して正常に検証されます。

6.7.3. oneOf

このキーワードの値は、空ではない配列でなければなりません。配列の各項目は、有効な JSON スキーマでなければなりません。

インスタンスは、このキーワードの値によって定義された1つのスキーマに対してのみ正常に検証された場合、このキーワードに対して正常に検証されます。

6.7.4. not

このキーワードの値は、有効な JSON スキーマでなければなりません。

インスタンスは、このキーワードによって定義されたスキーマに対して正常に検証されない場合に、このキーワードに対して有効です。

7. "format" を使用したセマンティック検証

7.1. はじめに

構造的な検証だけでは、インスタンスがアプリケーションのすべての要件を満たしていることを検証するのに十分でない場合があります。"format" キーワードは、RFCまたはその他の外部仕様である、信頼できるリソースによって正確に記述された値の固定サブセットに対して、相互運用可能なセマンティック検証を可能にするように定義されています。

このキーワードの値は、フォーマット属性と呼ばれます。文字列でなければなりません。フォーマット属性は、通常、特定のインスタンス型のセットのみを検証できます。検証するインスタンスの型がこのセットに含まれていない場合、このフォーマット属性とインスタンスの検証は成功するはずです。

7.2. 実装要件

"format" キーワードは、アノテーション(3.3節)とアサーション(3.2節)の両方として機能します。セマンティックな意味を伝えるアノテーションとして実装するために特別な努力は必要ありませんが、検証の実装は簡単なことではありません。

実装は、検証アサーションとして "format" キーワードをサポートしてもよい(MAY)。そうすることを選択した場合

実装は、カスタムフォーマット属性を追加してもよい(MAY)。当事者間の合意を除き、スキーマの作成者は、ピア実装がこのキーワードおよび/またはカスタムフォーマット属性をサポートすることを期待してはならない(SHALL NOT)。

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

7.3.1. 日付と時刻

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

日付と時刻のフォーマット名は、RFC 3339, section 5.6 [RFC3339] から派生しています。

フォーマットをサポートする実装は、次の属性のサポートを実装するべき(SHOULD)です

date-time
文字列インスタンスは、"date-time" 生成に従った有効な表現である場合、この属性に対して有効です。
date
文字列インスタンスは、"full-date" 生成に従った有効な表現である場合、この属性に対して有効です。
time
文字列インスタンスは、"full-time" 生成に従った有効な表現である場合、この属性に対して有効です。

実装は、そのセクションで定義されている他の生成名を使用して、追加の属性をサポートしてもよい(MAY)。"full-date" または "full-time" が実装されている場合、対応する短縮形(それぞれ "date" または "time")が実装される必要があり、同一に動作する必要があります。実装は、その生成のルールに従って検証する場合を除き、RFC 3339 生成に一致する名前で拡張属性を定義すべきではありません(SHOULD NOT)。[CREF2]現在、すべてのRFC 3339形式をサポートする必要性についてコンセンサスが得られていないため、この名前空間を予約するアプローチは、セット全体にコミットせずに実験を促進します。フォーマット実装要件が全般的に柔軟になるか、これらが完全に指定された属性に昇格するか、削除される可能性が高いでしょう。

7.3.2. メールアドレス

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

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

email
RFC 5322, section 3.4.1 [RFC5322] で定義されているとおり。
idn-email
RFC 6531 [RFC6531] で定義されているとおり。

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

7.3.3. ホスト名

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

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

hostname
RFC 1034, section 3.1 [RFC1034] で定義されているとおり。RFC 5891, section 4.4 [RFC5891] で指定されている Punycode アルゴリズムを使用して生成されたホスト名を含みます。
idn-hostname
hostname の場合と同様に RFC 1034 で定義されているか、RFC 5890, section 2.3.2.3 [RFC5890] で定義されている国際化されたホスト名で定義されているとおり。

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

7.3.4. IPアドレス

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

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

ipv4
RFC 2673, section 3.2 [RFC2673] で定義されている「ドット付きクワッド」ABNF構文に従ったIPv4アドレス。
ipv6
RFC 4291, section 2.2 [RFC4291] で定義されているIPv6アドレス。

7.3.5. リソース識別子

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

uri
文字列インスタンスは、[RFC3986] に従って有効な URI である場合、この属性に対して有効です。
uri-reference
文字列インスタンスは、[RFC3986] に従って、有効な URI 参照(URI または相対参照のいずれか)である場合、この属性に対して有効です。
iri
文字列インスタンスは、[RFC3987] に従って有効な IRI である場合、この属性に対して有効です。
iri-reference
文字列インスタンスは、[RFC3987] に従って有効な IRI 参照(IRI または相対参照のいずれか)である場合、この属性に対して有効です。

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

7.3.6. uri-template

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

文字列インスタンスは、[RFC6570] に従って、有効な URI テンプレート(任意のレベル)である場合、この属性に対して有効です。

URIテンプレートはIRIに使用できることに注意してください。個別のIRIテンプレート仕様はありません。

7.3.7. JSON ポインタ

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

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

絶対JSONポインタと相対JSONポインタの両方を許可するには、どちらかの形式をサポートすることを示すために "anyOf" または "oneOf" を使用します。

7.3.8. regex

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

正規表現。これは、ECMA 262 [ecma262] 正規表現方言に従って有効であるべきです(SHOULD)。

フォーマットを検証する実装は、この仕様の 正規表現 [regexInterop] セクションで定義されている ECMA 262 のサブセットを少なくとも受け入れる必要があり(MUST)、すべての有効な ECMA 262 式を受け入れるべきです(SHOULD)。

8. 文字列エンコードされた非JSONデータ

8.1. はじめに

このセクションで定義されているプロパティは、インスタンスにJSON文字列でエンコードされた非JSONデータが含まれていることを示します。それらは、コンテンツのタイプとエンコード方法を記述します。

これらのプロパティは、JSONデータをリッチマルチメディアドキュメントとして解釈するために必要な追加情報を提供します。

8.2. 実装要件

コンテンツキーワードは、アノテーション(セクション3.3)とアサーション(セクション3.2)の両方として機能します。アプリケーションが文字列内のデータを解釈する方法を伝えるアノテーションとして実装するために特別な努力は必要ありませんが、メディアタイプとエンコーディングへの適合性の検証を実装することは自明ではありません。

実装は、"contentMediaType" および "contentEncoding" キーワードを検証アサーションとしてサポートしてもよい(MAY)。そうすることを選択した場合、これらのキーワードの検証を無効にするオプションを提供すべきです(SHOULD)。

8.3. contentEncoding

インスタンスの値が文字列の場合、このプロパティは、文字列がバイナリデータとして解釈され、このプロパティで名前が指定されたエンコーディングを使用してデコードされるべきである(SHOULD)ことを定義します。RFC 2045, Sec 6.1 [RFC2045] は、このプロパティの可能な値をリストしています。

このプロパティの値は文字列である必要があります(MUST)。

このプロパティの値は、記述されたインスタンスが文字列でない場合は無視されるべきです(SHOULD)。

8.4. contentMediaType

このプロパティの値は、RFC 2046 [RFC2046] で定義されているように、メディアタイプである必要があります(MUST)。このプロパティは、このスキーマが定義するインスタンスのメディアタイプを定義します。

このプロパティの値は文字列である必要があります(MUST)。

このプロパティの値は、記述されたインスタンスが文字列でない場合は無視されるべきです(SHOULD)。

"contentEncoding" プロパティが存在しないが、インスタンスの値が文字列の場合、このプロパティの値はテキストドキュメントタイプを指定するべきであり(SHOULD)、文字セットはJSON文字列の値がデコードされた文字セットであるべきです(デフォルトはUnicode)。

8.5.

以下は、"contentEncoding" と "contentMediaType" の使用例を示すスキーマの例です。

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

                    

このスキーマで記述されたインスタンスは文字列である必要があり、それらの値はbase64エンコードされたPNG画像として解釈できる必要があります。

別の例

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

                    

このスキーマで記述されたインスタンスは、JSON文字列がデコードされた文字セット(デフォルトはUnicode)を使用して、HTMLを含む文字列である必要があります。

9. "definitions" を使用したスキーマの再利用

"definitions" キーワードは、スキーマ作成者が再利用可能なJSONスキーマをより一般的なスキーマにインライン化するための標準化された場所を提供します。このキーワードは、検証結果に直接影響しません。

このキーワードの値はオブジェクトである必要があります(MUST)。このオブジェクトの各メンバーの値は、有効なJSONスキーマである必要があります(MUST)。

{
    "type": "array",
    "items": { "$ref": "#/definitions/positiveInteger" },
    "definitions": {
        "positiveInteger": {
            "type": "integer",
            "exclusiveMinimum": 0
        }
    }
}

                    

例として、正の整数制約が "definitions" 内のサブスキーマである、正の整数の配列を記述するスキーマを以下に示します。

10. スキーマアノテーション

スキーマ検証は、インスタンスデータに追加情報を注釈付けするための便利なメカニズムです。アノテーションがインスタンスに関連付けられるタイミングと方法のルールについては、3.3項で概説しています。

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

10.1. "title" および "description"

これらのキーワードの値はどちらも文字列である必要があります(MUST)。

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

10.2. "default"

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

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

10.3. "readOnly" および "writeOnly"

これらのキーワードの値はブール値である必要があります(MUST)。これらのキーワードの複数の出現が単一のサブインスタンスに適用される場合、任意の一つの出現がtrue値を指定すると結果の値はtrueである必要があり、そうでない場合はfalseである必要があります(MUST)。

"readOnly" の値がブール値の true である場合、インスタンスの値が所有権限によって排他的に管理され、アプリケーションがこのプロパティの値を変更しようとすると、その所有権限によって無視または拒否されることが予想されることを示します。

ドキュメント全体で "readOnly" としてマークされているインスタンスドキュメントは、所有権限に送信された場合、無視されるか、権限の裁量でエラーが発生する可能性があります。

"writeOnly" の値がブール値の true である場合、値は所有権限からインスタンスを取得するときには存在しないことを示します。ドキュメント(またはそれが表すリソース)を更新または作成するために所有権限に送信するときに存在することができますが、インスタンスの更新または新しく作成されたバージョンには含まれません。

ドキュメント全体で "writeOnly" としてマークされているインスタンスドキュメントは、何らかの空白ドキュメントとして返されるか、取得時にエラーが発生するか、権限の裁量で取得要求が無視される可能性があります。

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

これらのキーワードは、ユーザーインターフェイスのインスタンス生成を支援するために使用できます。特に、アプリケーションは、書き込み専用フィールドの入力時に入力値を非表示にするウィジェットを使用することを選択できます。

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

10.4. "examples"

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

このキーワードは、使用例を示すために、特定のスキーマに関連付けられたサンプルJSON値を提供するために使用できます。これらの値は、関連付けられたスキーマに対して有効であるように推奨されます(RECOMMENDED)。

実装は、存在する場合は、"default" の値を追加の例として使用してもよい(MAY)。"examples" がない場合でも、"default" はこの方法で使用できます。

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

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

JSONスキーマ検証では、正規表現の使用が許可されています。正規表現には、多数の異なる(多くの場合、互換性のない)実装があります。一部の実装では、JSONスキーマの範囲外であり、許可してはならない(MUST NOT)任意のコードの埋め込みが許可されています。正規表現は、計算に非常にコストがかかる(いわゆる「壊滅的なバックトラッキング」)ように作成されることも多く、サービス拒否攻撃につながる可能性があります。

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

メディアタイプまたはエンコーディングの処理は、そのメディアタイプまたはエンコーディングのセキュリティに関する考慮事項に従います。たとえば、RFC 4329 スクリプトメディアタイプ [RFC4329] のセキュリティに関する考慮事項は、JSON文字列内にエンコードされた JavaScript または ECMAScript を処理するときに適用されます。

12. 参考文献

12.1. 規範的参考文献

, "
[RFC2119] Bradner, S., "RFCで要求レベルを示すために使用するキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月。
[RFC1034] Mockapetris, P., "ドメイン名 - 概念と機能", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1987年11月。
[RFC2045] Freed, N. および N. Borenstein, "マルチパーパスインターネットメールエクステンション(MIME)パート1:インターネットメッセージ本体の形式", RFC 2045, DOI 10.17487/RFC2045, 1996年11月。
[RFC2046] Freed, N. および N. Borenstein, "マルチパーパスインターネットメールエクステンション(MIME)パート2:メディアタイプ", RFC 2046, DOI 10.17487/RFC2046, 1996年11月。
[RFC2673] Crawford, M., "ドメインネームシステムでのバイナリラベル", RFC 2673, DOI 10.17487/RFC2673, 1999年8月。
[RFC3339] Klyne, G. および C. Newman, "インターネット上の日時:タイムスタンプ", RFC 3339, DOI 10.17487/RFC3339, 2002年7月。
[RFC3986] Berners-Lee, T., Fielding, R. および L. Masinter, "統一リソース識別子(URI):汎用構文", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005年1月。
[RFC3987] Duerst, M. および M. Suignard, "国際化リソース識別子(IRI)", RFC 3987, DOI 10.17487/RFC3987, 2005年1月。
[RFC4291] Hinden, R. および S. Deering, "IPバージョン6アドレス指定アーキテクチャ", RFC 4291, DOI 10.17487/RFC4291, 2006年2月。
[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月。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. および D. Orchard, "URIテンプレート", RFC 6570, DOI 10.17487/RFC6570, 2012年3月。
[RFC6531] Yao, J. および W. Mao, "国際化電子メールのためのSMTP拡張", RFC 6531, DOI 10.17487/RFC6531, 2012年2月。
[RFC6901] Bryan, P., Zyp, K. および 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月。
[ecma262]ECMA 262 仕様"
[relative-json-pointer] Luff, G. および H. Andrews, "相対JSONポインタ", インターネットドラフト draft-handrews-relative-json-pointer-01, 2017年11月。
[json-schema] Wright, A. および H. Andrews, "JSONスキーマ: JSONドキュメントを記述するためのメディアタイプ", インターネットドラフト draft-handrews-json-schema-01, 2017年11月。

12.2. 参考資料

[RFC4329] Hoehrmann, B., "スクリプトメディアタイプ", RFC 4329, DOI 10.17487/RFC4329, 2006年4月。

付録 A. 謝辞

JSONスキーマの初期ドラフト作成にご尽力いただいた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に感謝します。

付録 B. 変更履歴

[CREF3]このセクションは、インターネットドラフトの状態を離れる前に削除されます。

draft-handrews-json-schema-validation-01

draft-handrews-json-schema-validation-00

draft-wright-json-schema-validation-01

draft-wright-json-schema-validation-00

draft-fge-json-schema-validation-00

著者のアドレス

Austin Wright (編集者) メール: [email protected]
Henry Andrews (編集者) Cloudflare, Inc. サンフランシスコ, CA 米国 メール: [email protected]
Geraint Luff ケンブリッジ, 英国 メール: [email protected]