Fixing `contains` and `minContains`

[Greg Dennis]

Currently contains and minContains are defined so that if minContains has a value of 0, it changes the validation result of contains. There are two problems with this:

1. Keywords are allowed to change their own behavior, but not the behavior of other keywords

   Keywords MAY modify their behavior based on the presence or absence of another keyword in the same schema object - Core 7.2

2. contains is defined in Core, whereas minContains (and maxContains) is defined in Validation (the spec, not the vocab).

Ideally, all of the logic should be defined for contains: contains looks at minContains and maxContains to determine the appropriate bounds. This behavior fixes the first problem.

In order to address the second, we'd either need to move contains to Validation (but it's still an applicator), or we'd need to move minContains and maxContains to Core. There's also the issue that unevaluatedItems now depends on contains, which seems to support moving min/maxContains.

So, do min/maxContains work in Core? What vocab would they be a part of? The only vocab is applicators and they're not applicators.

Alternatively, can we move the entire applicator vocab out of Core into Validation? Does Core need applicators?

[Jason Desrosiers]

For some reason I though we had already taken care of this, but if we haven't, we definitely need to. I think it makes perfect sense for min/maxContains to be in the applicator vocabulary. The group of contains/minContains/maxContains are really one unit and minContains and maxContains are just modifiers of contains, so contains should determine where the whole set should go, which means it belongs in applicators.

[Greg Dennis]

Okay, yeah, it looks like they're grouped under "Other Keywords for Applying Subschemas." I didn't know we had done that already. (Although there is a typo of minContians in there 😄)

[Greg Dennis]

Closing this as the specific topic is resolved (already done).