dynamic enum on object's arbitrary key names?

[mewalig]

Below is an example JSON Schema:

{
  "type": "object",
  "properties": {
    "foo": { "type": "string" },
    "bar": { "type": "string" }
  },
  "required": ["foo"] # "bar" would also be ok, but "baz" would be invalid since it's not a key of "properties"
}

Suppose we wanted to describe the schema of JSON Schema using JSON Schema. How would we describe the requirements that "required" can only contain values that exist as keys to "properties"?

{
  "type": "object",
  "properties": {
    "properties": {
      "type": "object"
    },
    "required": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": "what goes here???"
      }
    }
  }
}

This is the similar to (but not the same as) the questions posted at https://stackoverflow.com/questions/57556768/use-object-keys-as-type-in-json-schema and #855.

[handrews]

The general form of this question is being tracked in #855. It's one of the more controversial topics remaining in JSON Schema, so don't expect a quick or easy answer.

[mewalig]

Yes, I'm aware of #855 but my intent was precisely to create a narrower scope for the following reasons, neither of which can generally be said to hold true for the broader scope of #855:

1. validators must at least handle this scope in order to validate the "required" keyword, so any discussion, concerns, etc related to actual implementation, validation etc can be informed by actual, well-used and real-world code bases
2. this feature is necessary (I think...) if we want JSON Schema to be complete enough to describe itself. Granted, I'm not sure if "complete enough to describe itself" has any intrinsic value but it feels like a noble cause in principle...

[Relequestual]

"bar" would also be ok, but "baz" would be invalid since it's not a key of "properties"

Where did you get that understanding from?

It's totally valid, and expected, to allow required to contain values not found in a properties object. In fact, I frequently use required without properties in the same schema object.

There are plenty of constructs of a JSON Schema which are valid but sensless or not useful, but it's impossible (I'd take an educated guess at this) to define them all, let alone constrain them all.

It's possible to create a JSON Schema which doesn't make any sense but is still valid. It's possible to combine schemas in a way which breaks expectations.

It sounds like what you want is a linter, not a validator. JSON Schema itself is not a linter. One is planned, but it's unlikely to be soon. You can check out an existing linter here: https://www.json-schema-linter.com/

[mewalig]

Ah, thank you! I just assumed that anything in required had to be specified in properties and did not realize that wasn't the case