[author of the draft v4 validation spec here]
You have stumbled upon the most common problem in JSON Schema, that is, its fundamental inability to do inheritance as users expect; but at the same time it is one of its core features.
When you do:
"allOf": [ { "schema1": "here" }, { "schema2": "here" } ]
schema1
and schema2
have no knowledge of one another; they are evaluated in their own context.
In your scenario, which many, many people encounter, you expect that properties defined in schema1
will be known to schema2
; but this is not the case and will never be.
This problem is why I have made these two proposals for draft v5:
Your schema for shipping_address
would then be:
{
"merge": {
"source": { "$ref": "#/definitions/address" },
"with": {
"properties": {
"type": { "enum": [ "residential", "business" ] }
}
}
}
}
along with defining strictProperties
to true
in address
.
Incidentally, I am also the author of the website you are referring to.
Now, let me backtrack to draft v3. Draft v3 did define extends
, and its value was either of a schema or an array of schemas. By the definition of this keyword, it meant that the instance had to be valid against the current schema and all schemas specified in extends
; basically, draft v4's allOf
is draft v3's extends
.
Consider this (draft v3):
{
"extends": { "type": "null" },
"type": "string"
}
And now, that:
{
"allOf": [ { "type": "string" }, { "type": "null" } ]
}
They are the same. Or maybe that?
{
"anyOf": [ { "type": "string" }, { "type": "null" } ]
}
Or that?
{
"oneOf": [ { "type": "string" }, { "type": "null" } ]
}
All in all, this means that extends
in draft v3 never really did what people expected it to do. With draft v4, *Of
keywords are clearly defined.
But the problem you have is the most commonly encountered problem, by far. Hence my proposals which would quench this source of misunderstanding once and for all!