Description
There is an example on the draft-06 release notes that demonstrates how to use propertyNames with anyOf to do inheritance that prevents additional properties (equivalent to additionalProperties: false behavior).
Quoted from: http://json-schema.org/draft-06/json-schema-release-notes.html
A workaround is available with the new "propertyNames" keyword:
{
"type": "object",
"allOf": [
{"$ref": "#/definitions/foo"},
{"$ref": "#/definitions/bar"}
],
"anyOf": [
{"$ref": "#/definitions/fooNames"},
{"$ref": "#/definitions/barNames"}
],
"definitions": {
"foo": {
"properties": {
"foo": {"type": "string"}
}
},
"fooNames": {
"propertyNames": {"enum": ["foo"]}
},
"bar": {
"properties": {
"bar": {"type": "number"}
}
},
"barNames": {
"propertyNames": {"enum": ["bar"]}
}
}
}
This will allow an object with either “foo” or “bar” or both, but will fail validation if any other property is present. The "allOf" ensures that “foo” and “bar” will each be validated correctly if present, while the "anyOf" allows for properties with names in either allowed set, but forbids properties that are not listed in at least one set.
Based on this description, it would be expected that the following JSON is valid against the schema above
{
"foo": "some string",
"bar": 42
}
However, there are no tests for this behavior and the JSON.NET Schema implementation at least does not implement this behavior as described (the JSON above is considered invalid because it does not satisfy the anyOf constraint -- each propertyNames definition is evaluated independently and so both fail validation with the other property).
At this point we probably just have to wait for draft-08 to fix this since it may not make sense to expect JSON.NET Schema and other draft-06 implementations to implement this properly given that there wasn't a test case for it.
But there should be a test added for draft-08 (or the propertyNames feature reconsidered altogether if it doesn't actually work as described above).