Closed gregsdennis closed 1 year ago
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.
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 😄)
Closing this as the specific topic is resolved (already done).
Currently
contains
andminContains
are defined so that ifminContains
has a value of0
, it changes the validation result ofcontains
. There are two problems with this:contains
is defined in Core, whereasminContains
(andmaxContains
) is defined in Validation (the spec, not the vocab).Ideally, all of the logic should be defined for
contains
:contains
looks atminContains
andmaxContains
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 moveminContains
andmaxContains
to Core. There's also the issue thatunevaluatedItems
now depends oncontains
, which seems to support movingmin/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?