ref.json "new scope when adjacent to keywords" test #636
-
Hello, I do not understand this ref.json test. This is related to this discussion. In the "toggle" example of the specification (section-7.7.1.1), the Kind regards, D. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
{
"type": "string",
"$ref": "#/$defs/foo",
"$defs": {
"foo": { "type": "number" }
}
} This example says that the JSON instance must be a string and must be a number. That's not possible, so any value you validate against this schema will fail validation. Let's look at another example where the conflicting keyword is an annotation that doesn't effect validation. {
"title": "Foo",
"$ref": "#/$defs/foo",
"$defs": {
"foo": { "title": "Bar" }
}
} What will be the title of the instance evaluated by this schema, "Foo" or "Bar"? It's really both, but because it doesn't effect validation, Section 7.7.1.1 allows applications (not validators) to choose one or the other. That section doesn't apply in the context of validation, only to how applications use the annotations that are provided after validation. Hopefully that background helps, so I'll try to answer the question directly. {
"properties": {
"prop1": { "type": "string" }
},
"$ref": "#/$defs/A",
"$defs": {
"A": { "unevaluatedProperties": false }
},
} So, here, |
Beta Was this translation helpful? Give feedback.
$ref
is not a merge. It's likeallOf
where all assertions apply independently. Therefore, it's possible to have conflicting assertions.This example says that the JSON instance must be a string and must be a number. That's not possible, so any value you validate against this schema will fail validation. Let's look at another example where the conflicting keyword is an annotation that doesn't effect validation.
What will be the title of the instance evaluated by this schema, "Foo" or "Bar"? It's rea…