✨ 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?