✨ Proposal: Not all keywords need to produce a validation result.

[gregsdennis]

Describe the inspiration for your proposal

The current specifications declare a validation result for every non-core keyword. On keywords for which a validation result doesn't really make sense, it says that validation must always pass or that they must always return a "true" validation result.

Examples are if, minContains, and maxContains. For the latter two, it's especially apparent since we've moved them into the Core spec alongside contains. Specifically, the WIP version states that these two keywords "modify the behavior of contains". Then it talks about validation for them.

If their purpose is to help contains do its job, why should they produce a validation result at all?

Describe the proposal

The spec should state whether a keyword should be ignored for validation purposes.

I think instead of each keyword needing to specify, we just have a single statement at the top that says something like

Keywords which do not specify a validation result do not participate in validation. Implementations MAY consider them to always return a validation result of "true".

This would need to go in Core.

Describe alternatives you've considered

No alternatives; just the proposal.

Additional context

This would also apply to all of the "pure annotation" keywords, like title and deprecated.

I like the idea of keywords having disjoint roles. It can help move us toward supporting other things people use JSON Schema for, like code/schema/form/docs generation.

[gregsdennis]

I've put this in the stable release project for now. I can remove it if we want to reserve this for a second release.

[jviotti]

I like the proposal. I wonder if we need another category for keywords (like assertions, applicators, etc) that goes something like "modifiers", so we have a word to talk about them?

[gregsdennis]

Actually, in line with #1447, I'm thinking that we need to specify these as behaviors. Categories seem exclusive, like a keyword can be in only one. But a keyword could have any number of behaviors. It's clearer to me thinking of it this way.

[jdesrosiers]

I like the suggested wording. Something being ignored and having a validation result of true is effectively the same thing. Implementations should feel free to use either approach as they see fit.

The only concern I see about stating this just once in Core is that most readers will never see it. I suspect few people read the full spec start to finish. Even if they do, most will forget that little detail by the time they get to something like minContains. I don't know if that's going to be a problem. It might not. It might be intuitive enough that if the spec doesn't mention validation behavior, there is no validation behavior. I don't know what's best here, but it's something to think about.