additionalProperties not set correctly if omitted or a boolean

[spacether]

Per the openapi v2 and greater spec definitions, additionalProperties should be set to empty schema {} if it is omitted. It is currently being set to null.

v2.0 points us to the https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md JSON schema Draft 4 definition, and OpenAPI does not tell us a default value.
Per here it sounds like an omitted additionalProperties should be an empty schema.

v3.0.0 points us to the https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md JSON Schema Specification Wright Draft 00 definition.
Wright Draft 00 mentions
If "additionalProperties" is absent, it may be considered present with an empty schema as a value.
v3.0.3 explicitly says that it defaults to true here: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md

Specifically from https://tools.ietf.org/html/draft-wright-json-schema-validation-00#page-10:

If "additionalProperties" is absent, it may be considered present with an empty schema as a value.

When additionalProperties is omited, how about we set it to {} for:

• object type schemas
• composed schemas
  So that we conform to the specs

[gracekarina]

Hi @spacether the 2nd PR is also failing, please fix so we can review and merge. thanks! I understand the first PR is to exposed the issue.

[spacether]

Thanks for pointing that out; just now I fixed the tests in my #1414 PR

[webron]

Jumping in a little bit late, but better late than...

While what you mention for v3 is true, for v2 it's not so much.

v2 has several inconsistencies and some missing information. When it comes to JSON Schema, it was due to the fact that nobody really knew JSON Schema well when the decision was made to use it.

In v2, despite what the specification might say, the default for additionalProperties was assumed to befalse and true/false value were not allowed. If you wanted to allow any additional property, you explicitly had to set it to an empty schema. As you probably already know, this has changed in v3, and have been better clarified there.

I don't think we should change the behavior for v2 - it should become more and more obsolete especially with the upcoming release of v3.1.

[spacether]

@webron do you have any references that show that decision/interpretation for v2?

[webron]

@spacether I find myself to be a reasonable reference in this case, given I was one of the people who wrote the spec ;)

[spacether]

Closing this due to the above answer