Another `unevaluatedProperties` test case

[gregsdennis]

Consider the following schema and instance:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "allOf":[
    {
      "properties": {
        "foo": true
      }
    },
    {
      "unevaluatedProperties": false
    }
  ]
}

{
  "foo": 1
}

This instance should be invalid because #/allOf/1/unevaluatedProperties can't see outside of its local subschema and has no idea that foo has already been evaluated.

Additionally, Section 9.2.1 is non-specific as to whether the applicator keywords are to be evaluated in sequence.

There may be other similar cases involving these applicators.

[karenetheridge]

JSON keys are unordered in the object, so I would assume that if it is ever important to consider keys in a certain order, the spec would say so. In most cases it doesn't matter -- a schema is invalid if any of its keywords produced an invalid result, so you can evaluate each keyword separately in any order.

There are a few keywords that depend on the results of other keywords - e.g. additionalItems depending on items, so you can think of those two being considered together rather than in isolation.

[gregsdennis]

@karenetheridge

you can think of those two being considered together rather than in isolation

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "properties": {
    "foo": true
  },
  "unevaluatedProperties": false
}

{
  "foo": 1
}

This time the instance is valid. In the initial case, the instance is invalid.

[karenetheridge]

That doesn't negate any of what I said. unevaluatedProperties is very explicitly documented as depending on the results (specifically, the annotation results) of properties + additionalProperties, so because of that dependency it must be considered after those other two keywords.

Still, in the general case, keyword evaluation can be unordered (although of course if you only care about a true/false result you can short-circuit and certain traversal patterns will be more efficient than others).

[gregsdennis]

it must be considered after those other two keywords.

This is only true within the context of a subschema. Because the allOf splits then into two subschemas, #/allOf/1 is processed as standalone and fails.

Schemas cannot see sibling schemas.

[karenetheridge]

This is only true within the context of a subschema.

I agree.

I've lost sight of what is being debated here :)

[karenetheridge]

I'm not sure if I was failing to understand the issue before, but I understand it now :) I agree with the intent of this patch.