unevaluatedProperties and unevaluatedItems should probably consider const and enum

[ChALkeR]

E.g.:

{
  anyOf: [
    { const: { foo: 30 } },
    { properties: { x: { type: 'string' } } }
  ],
  unevaluatedProperties: false
}

currently must fail per spec on { foo: 30 }, which doesn't seem to make sense.

Related: #810

[handrews]

@ChALkeR This is similar to how the following also fails:

{
  anyOf: [
    { required: [ foo ] },
    { properties: { x: { type: 'string' } } }
  ],
  unevaluatedProperties: false
}

JSON Schema separates assertions about properties (or array items) from applicator keywords that describe what properties (or items) may or may not be present. For now we have made the decisions that unevaluatedProperties, which is itself an applicator keyword describing what properties may or may not be present, only respects other such applicator keywords, and not assertions. This follows the behavior of additionalProperties, so it is consistent. This schema:

{
  const: { foo: 30 } },
  additionalProperties: false
}

will also fail on { foo: 30 }.

I agree it's weird and somewhat arbitrary, but it is the only way we could stay consistent with existing behavior. The solution is to simply do:

{
  anyOf: [
    { const: { foo: 30 } },
    { properties: {
      foo: true,
      x: { type: 'string' }
    } }
  ],
  unevaluatedProperties: false
}

This is different from #810 , because contains is another "what items may or may not be present" applicator keyword, rather than an assertion.

[karenetheridge]

Thinking about how unevaluatedProperties could be made to respect const object values (and to be consistent, it should also respect enum, surely?) -- const would have to create an annotation at the instance position which contained all the properties present in the object. (And it should also create an annotation of the highest index value when the data instance is an array type, so unevaluatedItems is consistent also.). This means that const would become the first/only keyword in the validator vocabulary to produce annotations. It feels like more inconsistency is being introduced here by these changes, not less?

[handrews]

@karenetheridge yeah I admit I'm skeptical of expanding the behavior here. See also #846 about requiredProperties that is effectively a shorthand for required + properties. Similar shorthands of constProperties or enumProperties could theoretically be created.

Although I rather expect all of these would be better as extension vocabularies since, by definition, they are not needed in terms of functionality, only convenience. But convenience on very large schemas can be a big deal!

[Relequestual]

@ChALkeR Would you also argue that you would expect additionalProperties to be effected by const or enum?

[Relequestual]

/remind me to close this issue if there's no reply in 14 days

[reminders]

@Relequestual set a reminder for Aug 8th 2020

[reminders]

👋 @Relequestual, close this issue if there's no reply

[Relequestual]

Closing due to no reply.