ドラフト-06 リリースノート

zyp-04 および fge-00 (ドラフト-04) から wright-01 (ドラフト-06) への移行に関するリリースノートです。

注意：ドラフト-07 がリリースされました。

ドラフト-07 のコアと検証は、ドラフト-06 と下位互換性があります。詳細については、そのドラフトの移行ノートを参照してください。

質問：ドラフト-04 とドラフト-06 の違いは何ですか？
質問：ドラフト-05 はどうなりましたか？
質問：「additionalProperties」を使用してスキーマを再利用することについてのすべての議論はどうなりましたか？

質問：ドラフト-04 とドラフト-06 の違いは何ですか？

下位非互換な変更

キーワード	変更	結果
`"id"`	`"$id"` に置き換えられました	`"id"` という名前のインスタンスプロパティと混同されなくなりました
`"$id"`	`"id"` を置き換えます	動作は同じです。`$` プレフィックスは他の 2 つの主要なキーワードと一致します
`"$ref"`	スキーマが期待される場合にのみ許可されます	`"$ref"` という名前のインスタンスプロパティを記述できるようになりました
`"exclusiveMinimum"` と `"exclusiveMaximum"`	キーワードの独立性の原則と一致させるために、ブール値から数値に変更されました	これらが以前 true であった場合は、値を対応する `"minimum"` または `"maximum"` 値に変更し、`"minimum"` / `"maximum"` キーワードを削除します。
`"type"`	`"integer"` の定義	ドラフト-04 では、`"integer"` はプリミティブ型としてリストされており、「小数部または指数部のない JSON 数値」として定義されています。ドラフト-06 では、`"integer"` はプリミティブ型とは見なされず、`"type"` キーワードのセクションでのみ「小数部がゼロの数値」として定義されています。`1.0` は、そのため、ドラフト-04 以前では有効な `"integer"` 型ではありませんが、ドラフト-06 以降では有効な `"integer"` 型です。両方のドラフトで、整数は小数部を含まずに JSON でエンコードされるべきであると述べていることに注意してください。

追加および下位互換性のある変更

キーワード	変更	結果
ブール値をスキーマとして	`"additionalProperties"` と `"additionalItems"` だけではなく、どこにでも許可されます	`true` は `{}` と同等であり、`false` は `{"not": {}}` と同等ですが、意図はより明確であり、実装はこれらのケースをより簡単に最適化できます。
`"propertyNames"`	追加されました	値ではなく、すべてのプロパティの名前を検証するスキーマを受け入れます
`"contains"`	追加されました	スキーマが少なくとも1つの配列項目を検証した場合に検証に合格する配列キーワード
`"const"`	追加されました	1要素の`"enum"`のより読みやすい形式
`"required"`	空の配列を許可します	空の配列は、プロパティが不要であることを示します
`"dependencies"`	プロパティの依存関係に空の配列を許可します	空の配列は、指定されたプロパティに依存関係がないことを示します
`"format": "uri-reference"`	追加されました	RFC 3986に従って相対URI参照を許可します。下記の`"uri"`をフォーマットとして説明するセクションを参照してください。
`"format": "uri-template"`	追加されました	RFC 6570準拠のURIテンプレート値を示します。JSON Hyper-Schemaの`"href"`で使用されています。
`"format": "json-pointer"`	追加されました	`/foo/bar`のようなJSONポインタ値を示します。 `#/foo/bar`のようなJSONポインタURIフラグメントには使用しないでください。それらに適したフォーマットは`"uri-reference"`です。
`"examples"`	追加されました	検証に影響を与えない例を配列で示します。`"default"`の値は、このキーワードの下で繰り返さずに例として使用できます。

フォーマット：`"uri"` vs `"uri-reference"`

技術的には変更ではありませんが、"uri"フォーマットの動作は明確に説明されておらず、多くの場合、誤って実装および使用されていました（ドラフト-04メタスキーマでも）。

"uri"は、絶対URI（スキームで始まる）が必要な場合にのみ使用してください。

相対パス、フラグメント、またはその他のスタイルのURI参照（RFC 3986に従う）が許容される場合は、"uri-reference"を使用してください。

ドラフト-04からドラフト-06への変換を提供する実装では、"uri"フォーマットを"uri-reference"に変換するオプションを提供することを検討するかもしれませんが、厳密な準拠のため、そのようなオプションはデフォルトで無効にする必要があります。

質問：ドラフト-05 はどうなりましたか？

ドラフト-05のコアと検証仕様は、ドラフト-04のより明確で読みやすい書き直しを目的としており、ドラフト-06の変更の堅固な基盤を提供することを意図していました。実装者は、「ドラフト-05」のサポートを実装または宣伝してはなりません。

ドラフト-04の公開直後の提案を実装することにより「ドラフト-05」をサポートしていた実装は、混乱を避けるために、そのサポートを削除するか、別の名前を付ける必要があります。

Q: `"additionalProperties"`を使用してスキーマを再利用することに関するすべての議論はどうなりましたか？

"additionalProperties"をtrue以外の値に設定するスキーマの再利用に関するいくつかの競合する提案があります。ほとんどの人は、それがfalseである場合を特に気にしていますが、true以外の値では同じ動作が発生します。

この分野のすべての提案は、ドラフト-08の中心となります。ドラフト-07でいくつかの選択肢を排除する上で進歩を遂げましたが、残された分岐は、ドラフトの中心的な焦点とすることを正当化するほど深いです(ドラフト-07の中心的な焦点はHyper-Schemaです)。

問題はそのようなことを試みると

データ

{ "type": "object", "allOf": [ { "$ref": "#/definitions/foo" }, { "$ref": "#/definitions/bar" } ], "definitions": { "foo": { "properties": { "foo": { "type": "string" } }, "additionalProperties": false }, "bar": { "properties": { "bar": { "type": "number" } }, "additionalProperties": false } }}

空でないオブジェクトインスタンスでは、検証は常に失敗します。"additionalProperties"は、各サブスキーマが別のサブスキーマで使用されているか、単独で使用されているかにかかわらず、同じ意味を持つことを保証するために、直近の"properties"と"patternProperties"のみを認識します。

そのため、この例では、インスタンスに「bar」プロパティがある場合、「bar」は「foo」ではないため、最初のサブスキーマは失敗します。「foo」プロパティがある場合、「foo」は「bar」ではないため、2番目のサブスキーマは失敗します。そして、他のプロパティは両方のスキーマに失敗します。

新しい"propertyNames"キーワードを使用すると回避策があります。

データ

{ "type": "object", "allOf": [ { "$ref": "#/definitions/foo" }, { "$ref": "#/definitions/bar" } ], "propertyNames": { "anyOf": [ { "$ref": "#/definitions/fooNames" }, { "$ref": "#/definitions/barNames" } ] }, "definitions": { "foo": { "properties": { "foo": { "type": "string" } } }, "fooNames": { "enum": ["foo"] }, "bar": { "properties": { "bar": { "type": "number" } } }, "barNames": { "enum": ["bar"] } }}

これにより、「foo」または「bar」、またはその両方を含むオブジェクトが許可されますが、他のプロパティが存在する場合、検証に失敗します。"allOf"は、「foo」と「bar」がそれぞれ存在する場合に正しく検証されることを保証し、"anyOf"は、いずれかの許可されたセットに名前があるプロパティを許可しますが、少なくとも1つのセットにリストされていないプロパティは禁止します。

名前の複製と"allOf"と"anyOf"の両方のかさばった使用が必要ですが、他のオプションよりも繰り返し回数が少なく、"foo"と"bar"のスキーマが異なる個人または組織によって管理される別々のファイルにある場合でも、かなり堅牢に再利用できます。