test(cross-draft): respect $schema when it follows $defs#944
Open
Lakshya77089 wants to merge 1 commit into
Open
test(cross-draft): respect $schema when it follows $defs#944Lakshya77089 wants to merge 1 commit into
Lakshya77089 wants to merge 1 commit into
Conversation
Keyword order is insignificant, so the dialect declared by $schema must apply to subschemas under $defs even when $defs appears first lexically. An implementation that builds $defs before reading $schema would use its default dialect and incorrectly treat prefixItems as an assertion here. Refs json-schema-org/JSON-Schema-Test-Suite issue on $schema ordering. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a test asserting that the dialect declared by
$schemais applied to subschemas under$defseven when$defsappears before$schemalexically. This covers the "keyword ordering MUST be insignificant" banner raised in the linked issue.The reported bug: an implementation that builds the
$defssubschemas before reading$schemaends up using its default dialect rather than the one the schema declares.How the test detects it
{ "$defs": { "list": { "prefixItems": [{ "type": "string" }], "minItems": 2 } }, "$ref": "#/$defs/list", "$schema": "https://json-schema.org/draft/2019-09/schema" }prefixItemsis not a keyword in 2019-09, so[1, 2, 3]is valid only if the implementation read$schema(and selected the 2019-09 dialect) before building$defs. An implementation that defaulted the dialect would treatprefixItemsas an assertion and reject the array — failing thevalid: truetest.minItems(recognized in both dialects) gives a stable invalid case as well.The case lives in
optional/cross-draft.jsonbecause detecting the bug inherently requires a root$schemathat differs from the folder's default dialect, which is the same situation the existing cross-draft cases exercise.tests/latestis a symlink todraft2020-12, so it is covered automatically.Verified locally: structurally valid against
test-schema.json, valid under the 2020-12 metaschema (check_schema), and a$schema-respecting reference implementation returns the expectedtrue/false.Note for reviewers
I added this only in the 2020-12 → 2019-09 direction. The mirror (an older-draft folder declaring a newer inner
$schema) trips the suite'stest_arbitrary_schemas_do_not_use_unknown_keywordsguard when the newer keyword appears inline, and the clean older-dialect discriminators tangle with$ref-sibling semantics. Happy to add the other direction via remotes if that's preferred.🤖 Generated with Claude Code