Description
This is a pretty subtle wording issue, and easily fixed, if we agree on the desirabilities of the underlying principles.
The wording for validating the additionalProperties keyword against an object (independent of its children) has changed from the following in v4 (fge-00):
Successful validation of an object instance against these three
keywords depends on the value of "additionalProperties":
if its value is boolean true or a schema, validation succeeds;
if its value is boolean false, the algorithm to determine
validation success is described below.
To this in v5 (wright-00):
The value of "additionalProperties" MUST be a boolean or a schema.
If "additionalProperties" is absent, it may be considered present
with an empty schema as a value.
If "additionalProperties" is true, validation always succeeds.
If "additionalProperties" is false, validation succeeds only if the
instance is an object and all properties on the instance were covered
by "properties" and/or "patternProperties".
If "additionalProperties" is an object, validate the value as a
schema to all of the properties that weren't validated by
"properties" nor "patternProperties".
Oddly, the wording of "additionalItems" has not been changed to have this problem- it still preserves the behavior it had in v4.
The old wording had the following properties, which are lost in the new wording:
- Whether or not the object itself validated could be calculated independent of the validation outcomes of its children.
- The validation effects of
properties,patternProperties, andadditionalPropertieswith respect to the object itself were independent:propertiesdid not affect validation - as an object validation keyword, it always succeedspatternPropertiesdid not affect validation - as an object validation keyword, it always succeedsadditionalPropertiesalways fails for the valuefalseand always succeeds otherwise, no matter the value of the other two keywords
This language change significantly affects the theoretical model and the principles discussed in #55 as it is no longer possible to return a validation result of the object without calculating the validation results of its children.
I previously complained about the confusion of separating child validation from object validation but I was completely wrong to do so. Once I started working through a lot of schema algebra in an effort to solve the reuse-with-additionalProperties-false problem, the value of the separation became very apparent.
The correct solution is to more clearly correlate the object and child validation without tying them together. The v4 wording read strangely because it appeared to completely ignore child values, rather than explaining how and why object (and array) validation is independent of child validation, and fit it into the overall framework of many independent validation decisions which are only combined after their evaluation.