Closed schema with undefined required property – valid or invalid?

[frankkilcommins]

If you have a closed schema additionalProperties: false, which specifies an undefined yet required property, should the schema be valid or invalid?

The common interpretation I see is that the schema is valid. Would there be merit in classifying should a schema as invalid to prevent ambiguity for tools enabling schema authorship and for the schema authors?

Example Schema:

{
  "$id": "https://json-schema.hyperjump.io/schema",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "description": "The address associated with an object (person, customer, office, etc.)",
  "type": "object",
  "properties": {
    "addressLine": {
      "type": "string",
      "description": "The address line component includes, but is not limited to, details such as street name, street number, house number, house number addition, building name"
    },
    "city": {
      "type": "string",
      "description": "The city name for the address"
    },
    "postalCode": {
      "type": "string",
      "description": "The postal code for the address"
    },
    "region": {
      "type": "string",
      "description": "The address region. For the US this holds the state name, for the UK and Ireland, this holds the county name."
    },
    "country": {
      "type": "string",
      "pattern": "[a-zA-Z]{2}",
      "description": "The official (ISO) two-letter country code"
    }
  },
  "required": [
    "addressLine",
    "city",
    "postalCode",
    "country",
    "planet"
  ],
  "additionalProperties": false
}

It seems possible that you can get to a situation where the instance cannot honor the schema. Instances trying to conform to the schema generally result in a dead-end from a validation failure perspective:

1. Instances not satisfying the required properties constraint will fail

{
  "addressLine": "string",
  "city": "string",
  "postalCode": "string",
  "region": "string",
  "country": "string"
}

Error (planet missing and required):
• # fails schema constraint required

2. Instances satisfying the required properties constraint will fail on the additionalProperties constraint

{
  "addressLine": "string",
  "city": "string",
  "postalCode": "string",
  "region": "string",
  "country": "string",
  "planet": "string"
}

Error (planet supplied but invalid as it’s a closed schema):
• # fails schema constraint additionalProperties

I've spotted some implementation nuances regarding how this is interpreted (not exhaustive):

• www.json-schema-linter.com - Invalid Schema – “Required key(s) "planet" not found in named properties.” Note - It also complains if schema is open!
• www.jsonschemavalidator.net - Valid Schema – Instance validation dead-end
• jsonschema.dev - Valid Schema – Instance validation dead-end
• https://json-schema.hyperjump.io/ - Valid Schema – Instance validation dead-end

[jdesrosiers]

There are many ways in JSON Schema to construct schemas that always "dead-end" as you put it. A JSON Schema is just a collection of assertions. If a validator knows how to evaluate each assertion, the schema is valid. But, if you add two assertions that are mutually exclusive, you'll get a dead-end (Example: { "allOf": [{ "type": "string" }, { "type": "boolean" }] }). That's a whole other class of problem and one all programming languages have. Consider that the following is a valid program that also has a dead-end.

if (x < 5 && x > 7) {
  console.log("I see dead code");
}

Most programming languages have tools that are often called "linters" to statically (with out running the code) analyze the code to look for potential problems like unreachable code. www.json-schema-linter.com isn't a validator, it's a linter. That's why it detected your dead-end case and the others didn't. Its purpose is to detect those kinds of problems. It's telling you that your schema probably has a problem, not that it's invalid. All the other implementations you linked to are validators. Their purpose is to execute schemas. As long as they understand the assertions, they can do their job. We definitely want to see more and better linters for JSON Schema to help detect these kinds of problems in the future.

[frankkilcommins]

Thanks for taking the time to respond @jdesrosiers. The dead code example you provide is arguably subtly different but no value is discussing that here.

I'm fine with classing this as a linting responsibility. Thanks for clarifying and agree that having linters to do this will greatly help, especially when taking schemas as the starting point for codegen etc.