atMostOneOf and noneOf applicators

[ksperling]

In some situations it would be useful to have an atMostOneOf applicator to express mutual exclusivity without requiring one of the alternatives to be valid. For two options this can be expressed as not allOf but for more than two it becomes difficult.

Similarly, a noneOf applicator can sometimes be useful to express a set of negative constraints (though this can be expressed with not anyOf, noneOf would read more intuitively to a human).

[handrews]

@ksperling These sorts of keywords will be good uses of the new extensible vocabularies feature in the forthcoming draft. We are currently improving the wording around this feature based on pre-publication feedback, but otherwise the draft is about ready to go out.

We want to keep the standard keyword sets minimal, and as you note both of these concepts can be expressed with the current keywords.

However, folks who want to design and publish their own keyword sets will now be able to do so, and be able to signal to implementations that an extension is required- the idea is that implementations can offer a way to register a plugin to handle such extensions.

A convenience vocabulary for more complex logical operations would be an excellent use case for an extension vocabulary.

Otherwise, we will never get to any sort of finished RFC as there are endless reasonable possible keywords that people want.

[gregsdennis]

I've opened #43 to propose a single vocab that contains combinations of keywords like this.