Confirm use of OpenAPI's Schema Object

[tedepstein]

The spec says that extension property schemas should be OpenAPI Schema Objects. At first blush, this seems consistent with this stated design goal:

Common Technology Stack with OpenAPI, so that essential functions like YAML editing, schema validation, and JSON reference resolution can be performed by the same components used with OpenAPI tool implementations.

But, while Schema Object is implemented by certain OpenAPI tools and components (parsers, documentation UIs, code generators, etc.), it's not part of the technology stack used to implement those tools and components.

Pros

• Puts limits on the use of certain features of JSON schema. (Both a 'pro' and a 'con')
• Adds its own syntax and semantics for discriminators, format, etc. (Both a 'pro' and a 'con')
• Lets us use the OpenAPI convention of allowing markdown in description in top-level schemas, property sub-schemas, etc. This could be useful if we want to use SEMOASA to produce rich-formatted documentation of Specification Extensions, though that is not stated as one of the intended use cases.

Cons

• Puts limits on the use of certain features of JSON schema. (Both a 'pro' and a 'con')
• Adds its own syntax and semantics for discriminators, format, etc. (Both a 'pro' and a 'con')
• Libraries that enforce these constraints, implement these extended semantics, and render markdown descriptions may not be readily available, except in OpenAPI tools. Making them available in a lower-level stack, used by tool providers to create those tools might require significant refactoring. It might just not be practical to do this.