Mike Ralphson

> Exact same case for my team as well! A vote from me as well. Please use the GitHub reactions functionality on the original post. We can track that, whereas...

See also the [schema.org WebAPI](https://pending.schema.org/WebAPI) type, where the documentation property can point to an OpenAPI definition.

I've scanned ~200,000 OpenAPI documents and apart from my test file, I've found precisely 3 occurrences of a `pathItem` object having a `$ref` and one or more `operation` objects (all...

@dkoston @petermorlion my personal take is that this is functionality which belongs in a pre-processing tool, not within the OAS itself. That way you can guarantee no leaks of internal...

> The real issue is that there are properties of some routes that make it so they should be treated differently Unless there is some consensus on what "treated differently"...

Thanks for this. We deliberately started small with the scope of this feature with the hope of collecting more data points about what properties people would find it useful to...

As a result of #2604 the filename for this proposal should change to use a dated prefix. Please could you update this PR to match? Apologies for the extra work.

A good candidate for a `ui` / `forms` / `documentation` vocabulary to extend JSON Schema.

For consistency, if someone does take this to a PR, fields like `type` and `enum` should be wrapped within a standard `schema` field of type `schemaObject`.

If we moved to representing all `in:query` parameters as an object described by [a single JSON schema](https://github.com/OAI/OpenAPI-Specification/issues/256#issuecomment-780989715), then we would get this functionality 'for free' with the existing `additionalProperties` keyword.