keywords only exhibit the behaviors they're defined with #1577
Conversation
|
So, what is the result of: and and ? |
|
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. |
There was a problem hiding this comment.
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.
gregsdennis
force-pushed
the
gregsdennis/validation-not-required
branch
from
285a554 to
1a7a34a
Compare
Co-authored-by: Jason Desrosiers <[email protected]>
Co-authored-by: Jason Desrosiers <[email protected]>
Co-authored-by: Jason Desrosiers <[email protected]>
…redefining keywords
| 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. | ||
|
|
||
| Implementations SHOULD NOT add unspecified behaviors to keywords. |
There was a problem hiding this comment.
I'm not sure what this is aiming to prevent.
Behaviors outside the three above? I'm not sure what that would be. That also seems more the concern of the definition of an extension keyword rather than an implementation.
Or behaviors within the three, but that aren't in a specification? If so, that seems just the nature of a specification, that an implementation of it sticks to its specified behaviors.
| For the purposes of this document, an instance "validating against a keyword" | ||
| means that the keyword produces an assertion result of `true` if the instance | ||
| satisfies the given constraint; otherwise an assertion result of `false` is | ||
| produced. |
There was a problem hiding this comment.
This references Core Spec Keyword Behaviors but then also repeats, or is redundant with, a significant amount of that section.
There was a problem hiding this comment.
The validation spec uses the phrase "an instance validates against this keyword if...", or some variant of it, quite a lot. I just wanted to define what that means. The phrasing is different than "this keyword exhibits assertion behavior by...", which feels more clunky to me (and I'd have to change a lot of places).
Co-authored-by: Jason Desrosiers <[email protected]>
Co-authored-by: Jason Desrosiers <[email protected]>
Co-authored-by: Ethan <[email protected]>
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 fromcontainsand 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.