Why required is not an element property? - json

Question

Current schema example:
{
"$schema": "http://json-schema.org/schema#",
"type": "object",
"properties": {
"id": {
"type": "string",
"uniqueItems": true
},
"name": {
"type": "string"
},
"age": {
"type": "number"
},
"description": {
"type": "string"
}
},
"required": ["id", "name", "age"]
}
This to me is counterintuitive. It requires to repeat the property names and repetition is bad. I would have expected this instead:
{
"$schema": "http://json-schema.org/schema#",
"type": "object",
"properties": {
"id": {
"type": "string",
"uniqueItems": true,
"required": true
},
"name": {
"type": "string",
"required": true
},
"age": {
"type": "number",
"required": true
},
"description": {
"type": "string"
}
}
}
Is there a technical reason for required being an array where you have to repeat the property names? Is this approach superior in any way?

Answer 1

The set of required keys is an attribute of an object, not of its individual properties. That is, a predefined property
{
...
"$defs": {
"age_property": {
"type": "number"
}
}
...
}
may be required by one object
{
"type": "object",
"properties": {
"age": { "$ref": "#/$defs/age_property" },
...
},
"required": ["age", ...]
}
but not another
{
"type": "object",
"properties": {
"age": { "$ref": "#/$defs/age_property" },
...
},
"required": [...]
}

Answer 2

tl;dr
It has to do with what the keyword is actually evaluating. It's evaluating the container for the property's presence; the subschema in /properties is checking the value, if there is one.
Explanation
(source: I'm one of the specification authors and a validator implementor)
required used to be a keyword that was contained inside a property definition. As of draft 4, it was moved to it's own root-level keyword.
The value inside properties is always to be a schema. This subschema should stand alone, unaware that it's contained within a larger schema. As a schema, its function is to evaluate a value, but it has no knowledge of the origin of the value. In the case of properties, this is a value from a key-value pair. Again, it has no knowledge of the key or the object that contains it.
If required were part of the property definition, it would be validating not the value of the property, but the object that contains it. This is the responsibility of the parent schema.
An example:
// schema
{
"type": "object",
"properties": {
"a": { "type": "string" },
"b": { "required": true }
}
}
// instance
{ "b": "some value" }
/properties/b ({"required":true}) is instructed to evaluate "some value". How can required know that this value comes from an object and is under the b property? It would need knowledge of the value's parent to do that. (JSON Schema validators had to bend themselves into funny shapes in order to support this.)
The solution was to move required out of the property and into the schema that is evaluating the object itself.
// schema
{
"type": "object",
"properties": {
"a": { "type": "string" }
},
"required": [ "b" ]
}
// instance
{ "b": "some value" }
Now, required can evaluate the full object, and it can check whether that object contains a b property. Because there is no /properties/b in this case, any value is fine, so long as b is present.
Unfortunately, the discussion around moving this keyword has been lost as the current GitHub repo was set up after the move from draft 3 to draft 4.

Answer 3

The written specification is not based on real world application. See https://github.com/json-schema-org/json-schema-spec/issues/725 from the one who's probably done most practical use of json schema (ajv lib's author).
There is no right or wrong about the approach, but it is going to be useful for wide range of application or not is questionable. There are TONS of debates around this specification.
IMO, yes required makes impossible state possible (out-of-sync)

Answer 4

there is no technical reason, who designed jsonschema decided to use an array instead of element properties, pheraps because in this way you have all the required elements name near standing.