| Tag | Value |
|---|---|
| Proposal | YYYY-MM-DD-Short-Name |
| Authors | Author 1, Author 2 |
| Review Manager | TBD |
| Status | Proposal, Draft, Promoted, or Abandoned |
| Implementations | Click Here |
| Cross-Reference | Assign a unique label for this proposal, keeping the "Proposal-" prefix, and edit the label filter in the links. Label: Proposal-Xref-Label Related Issues Related Pull Requests |
| Previous Revisions | {revid} |
| Date | Responsible Party | Description |
|---|
A short description of what the feature is. Try to keep it to a single-paragraph "elevator pitch" so the reader understands what problem this proposal is addressing.
Describe the problems that this proposal seeks to address. If the problem is that some common pattern is currently hard to express, show how one can currently get a similar effect and describe its drawbacks. If it's completely new functionality that cannot be emulated, motivate why this new functionality would help OpenAPI developers create better code.
Describe your solution to the problem. Provide examples and describe how they work. Show how your solution is better than current workarounds: is it cleaner, safer, or more efficient?
Describe the design of the solution in detail. This should include an exact description of the changes to the contents of the OpenAPI specification. That description should include a extract of each section of the OpenAPI specification which is impacted by the proposal with all proposed modifications applied. These extracts may be provided through additional files which are identified and described in this section.
Proposals should be structure so that they can be handled by existing OAS compliant software. Any potential issues should be identified and discussed.
Describe alternative approaches to addressing the same problem, and why you chose this approach instead.