Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

additionalProperties and switch don't mix very well together #410

Closed
kapouer opened this issue Feb 8, 2017 · 3 comments
Closed

additionalProperties and switch don't mix very well together #410

kapouer opened this issue Feb 8, 2017 · 3 comments
Labels

Comments

@kapouer
Copy link
Contributor

kapouer commented Feb 8, 2017

I'm an objection user, and i've implemented a 'block' schema that can be extended depending on the value of a type property, using switch keyword: an example schema and data here.
However, when i try to add additionalProperties: false somewhere in that schema, it either just doesn't work if i put it on the root properties object, or complains about properties (supposedly) inherited from the root properties object if i put it on the switch properties objects.
It looks like there is some problem with the specification but i figured i would talk about it here before reporting anything to https://github.com/json-schema-org/json-schema-spec.

@kapouer
Copy link
Contributor Author

kapouer commented Feb 8, 2017

Using ajv@4.11.2

@epoberezkin
Copy link
Member

epoberezkin commented Feb 8, 2017

@kapouer "additionalProperties" keyword only takes into account the properties and patternProperties in the same schema object, properties defines in other objects in the schema schema are not taken into account. This behaviour is per spec.

The is no such thing as "inheritance" in JSON schema. The easy way to think about it is to see JSON schema as a set of restrictions that should be satisfied for the data to be valid. Each keyword applies restrictions according to strictly defined rules. While in simple cases JSON schema looks like a definition of the object structure, in general case it is not. In this way "properties" keyword does not define properties, it defines restrictions on property values if they are present in the object. So "properties" keywords defined in different places of the same schema are not supposed to be merged or treated together and "additionalProperties" keyword is not supposed to take them all into account. That follows from one important design principle of JSON schema that it is shallow and the result of validation of any keyword can only depend on sibling keywords in the same object, but not on any other keywords present anywhere else in the schema.

This limitation is a known one, there are multiple discussions about how to address this problem and no clear consensus at the moment.

There are several workarounds though: see #134 (comment)

@kapouer
Copy link
Contributor Author

kapouer commented Feb 8, 2017

Thank you for the explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants