Feature request: standard file that describes what openapi features are supported by an implementation

[spacether]

Feature request: standard file that describes what openapi features are supported by an implementation

If all implementations provided a yaml or json file of what features were supported it would allow for easier comparison of implementations.

What if we did this with the json schema descriptions of the openapi spec:
https://github.com/OAI/OpenAPI-Specification/blob/main/schemas/v3.0/schema.yaml

And the json path was the feature, like:
#/servers and the value is a boolean or a FeatureSupportInfo object like so:

FeatureSupportInfo:
  type: object
  properties:
    supported:
      type: boolean
    docUrl:
      type: string
    verificationTestUrl:
      type: string
  required:
  - supported

[darrelmiller]

Can you give examples of the types of features you would like to describe? I think it would be challenging to use a bool value to describe many OpenAPI features. In JSON Schema a validator keyword either validates or it doesn't. An Annotation either holds the annotation or it doesn't. I'm not sure how to map that to OpenAPI.

[handrews]

@darrelmiller it might be possible to correlate some things with the semantic output format I'm working on for the reference* parser implementation. If we have an identifier for certain semantics described by the file, then a tool could say one of:

• yes, we understand these semantics and do whatever we think our tool should do for them
• these semantics are not relevant to our tool
• no, we do not support these semantics although they are potentially relevant to our tool

There is a fair amount of work to be done before we can look at the identifiers and figure out how much this would make sense. And whether the level of detail in the semantic output format is sufficient for what @spacether has in mind.

@darrelmiller I think I agree with the concern that it's not possible to have a simple boolean feature support list. @spacether I'd also caution against making then format too complex and requiring people to type in too many explanations. A file like this will only be used if it's not much effort to fill out and delivers real value.

*reference as in "this is an example to follow" not "$ref" — is there a more clear name we could call this thing?

[MikeRalphson]

"Compliance parser"?

[handrews]

COMPLIANCE!