Skip to content

additionalProperties behavior for non-object instances #103

Closed
@handrews

Description

@handrews

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, and additionalProperties with respect to the object itself were independent:
    • properties did not affect validation - as an object validation keyword, it always succeeds
    • patternProperties did not affect validation - as an object validation keyword, it always succeeds
    • additionalProperties always fails for the value false and 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions