Why does the JSON schema for 3.0 specify patternProperties for component names but allows additional properties?

[handrews]

Discussed in https://github.com/OAI/OpenAPI-Specification/discussions/2439

^{Originally posted by ryankinderman January 11, 2021} I've been working on some functionality that uses the JSON schema to help validate OpenAPI schemas, and recently noticed that the 3.0 schema allows any value for {name} in /components/{component}/{name}, while the specification states that "All the fixed fields declared above are objects that MUST use keys that match the regular expression: ^[a-zA-Z0-9\.\-_]+$." It seems like this could have been validated automatically by simply adding additionalProperties: false to the JSON schema.

My question is: Was not including additionalProperties: false in the JSON schema for 3.0 just an accidental omission, or was there some rationale behind not doing it?

Thanks for clarifying!

[handrews]

@karenetheridge want to take a look with your schema work?

[karenetheridge]

I wasn't involved in the 3.0 schema development, but it does appear that this is an oversight, as I don't see why additionalProperties: false couldn't be included in each of the definitions under /components. However, this restriction is reflected in the 3.1 and 3.2 schemas.

[ralfhandl]

Should we set up schema maintenance for 3.0 and fix this?

[karenetheridge]

Is it difficult to do? I can send a PR for the schema change.

[ralfhandl]

Not particularly difficult, I've outlined the steps in

• #4986

@karenetheridge Feel free to work on the ToDo list, in branch v3.0-dev-wip. The unusual branch name avoids the strict rules for dev branches while setting it up.