Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

keywords only exhibit the behaviors they're defined with #1577

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

keywords only exhibit the behaviors they're defined with #1577

wants to merge 1 commit into from

Conversation

gregsdennis
Copy link
Member

What kind of change does this PR introduce?

clarification

Issue & Discussion References

Summary

The previous language could imply that all keywords needed to have an assertion result, e.g. annotations would always produce a "true" assertion result.

For min/maxContains, I added explicit text that they do not produce an assertion result, emphasizing that the assertion comes from contains and that these keywords are informative.

This change clarifies that keywords only exhibit the behaviors they're defined with.

Does this PR introduce a breaking change?

No.

@gregsdennis gregsdennis requested a review from a team January 19, 2025 07:24
@gregsdennis gregsdennis added this to the stable-release milestone Jan 19, 2025
@gregsdennis gregsdennis self-assigned this Jan 19, 2025
@karenetheridge
Copy link
Member

karenetheridge commented Jan 19, 2025 •
edited
Loading

So, what is the result of:

allOf: [
  { maxContains: 1 },
  { maxContains: 1 },
]

and

anyOf: [
  { maxContains: 1 },
  { maxContains: 1 },
]

and

oneOf: [
  { maxContains: 1 },
  { maxContains: 1 },
]

?

@gregsdennis
Copy link
Member Author

Good point. The keywords produce no assertions, but the subschemas still need to.

Granted, this is true with 2020-12, too. The validation spec doesn't actually define assertion results for any of the annotations, yet it's still considered a pass because there are no constraints.

I think this could be stated explicitly.

jdesrosiers
jdesrosiers requested changes Jan 20, 2025
View reviewed changes
Copy link
Member

@jdesrosiers jdesrosiers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've always thought of all keywords having an assertion. Annotation-only keywords just always assert true. $defs is another example of a keyword always returns true although it's not an annotation.

I think the way this is worded is great because it allows for implementations to ignore non-assertions or just make them true. They can implement it however makes most sense for their implementation.

specs/jsonschema-core.md
annotations in particular are extremely flexible. Complex behavior is usually
better delegated to applications on the basis of annotation data than
implemented directly as schema keywords. However, extension keywords MAY define
other behaviors for specialized purposes.

Keywords which are not defined to exhibit a particular behavior MUST NOT affect
that aspect of evalution. For example, a keyword which does not act as an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
that aspect of evalution. For example, a keyword which does not act as an
that aspect of evaluation. For example, a keyword which does not act as an

specs/jsonschema-core.md
satisfies the given constraint; otherwise an assertion result of `false` is
produced.

<!-- The next two paragraphs and the following section seem to have to more to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<!-- The next two paragraphs and the following section seem to have to more to
<!-- The next two paragraphs and the following section seem to have more to

specs/jsonschema-validation.md
the [JSON Schema Core Specification](./jsonschema-core.md#keyword-behaviors).

Keywords which are not defined to exhibit a particular behavior MUST NOT affect
that aspect of the evalution outcome. In particular, the keywords defined in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
that aspect of the evalution outcome. In particular, the keywords defined in
that aspect of the evaluation outcome. In particular, the keywords defined in

specs/jsonschema-core.md
Comment on lines +587 to +588
any boolean logic operation to the assertion results of subschemas, but MUST NOT
introduce new assertion conditions of their own.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but MUST NOT introduce new assertion conditions of their own.

I'm not following this. What is this trying to say? What are we protecting against be forbidding it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jdesrosiers jdesrosiers jdesrosiers requested changes

Requested changes must be addressed to merge this pull request.

Assignees

@gregsdennis gregsdennis

Labels
core validation
Projects
Stable Release Development
Status: In Progress
Milestone
stable-release
3 participants
@gregsdennis @karenetheridge @jdesrosiers