-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.1.1 set release date #4157
Merged
Merged
3.1.1 set release date #4157
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Encoding Object's `contentType` field takes a comma-separated list of either regular or wildcared media types. These are the "two types" mentioned in the previous wording – "two" here did *not* refer to a limit on the number of entries in the list. These are not exactly media-type or media-range values, as both of those include parameters. This change also moves the hard-to-follow list of default values out of the individual field cell and into its own table. It takes `Content-Disposition` out of the header field's cell and instead explains limitations on header usage, and explains how `Content-Disposition` is used for encoding. This explanation includes a suggestion on how other `multipart` formats could be used with an Encoding Object, since their unnamed parts otherwise cannot be supported. Finally, it clarifies the interaction between `contentType` and the three fields imported from the Parameter Object, by aligning the recommended (but not, for compatibility reasons, required) behavior with guidance added in 3.1.0.
Co-authored-by: Ralf Handl <[email protected]>
Thanks to @notEthan for the comments!
This splits the Encoding Object's fixed fields table to make the usage more clear, and closer to how it is presented for the Parameter and Header Objects
🤦 thanks for catching this, @ralfhandl Co-authored-by: Ralf Handl <[email protected]>
Encoding Object content and header clarifications (3.0.4)
Percent-encoding is a minefield, although in practice it mostly works. This appendix attempts to acknowledge the concerns and then define enough terminology and link to enough other specifications that interested readers will be able to research further details.
"serialization" matches other discussions, "rendering" does not.
Co-authored-by: Ralf Handl <[email protected]>
This is to make sure PR checks pass even though the PR adding Appendix C has not yet been merged.
This aligns all examples with RFC6570 operator prefixing behavior, which was previously only shown for `matrix` and `label`. The non-RFC6570 styles (`spaceDelimited`, `pipeDelimited`, and `deepObject`) are treated as analogues of `form` and therefore prefixed with a `?`. The lack of suitablity of this for cookie parameters has been addressed with an appendix in another change, and the appendix has been stubbed out here to ensure that the link is valid.
This was confusing, and my initial use of _e/s_ was too novel. Switch the column heading to "undefined" to align with RFC6570 and make clear that it is not about `allowEmptyValue`
That style is not usable for the Header Object anyway.
Appendix for percent-encoding concerns (3.0.4)
This clarifies how to handle resolving implicit (non-URI-based) connections in multi-document OpenAPI Descriptions. While the behavior is implementation-defined overall, this RECOMMENDS a single approach based on how things behaved going back to the 2.0 referencing model. This allows Security Schemes and Tags to (like the top-level Server Objects) define a deployment-specific interface for referenced documents to access. This entry document interface approach makes less sense for the Discriminator Object, but it can use the URI syntax of `mapping` to keep things within the local document. This also aligns the search for matching `operationId`s with 3.1's full-document parsing requirements. Note that the term "complete OpenAPI document" has been defined in another change pending approval on the 3.0.4 branch.
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Jeremy Fiel <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Jeremy Fiel <[email protected]>
An off-by-one caused respec to change all subsequent heading levels.
The XML Object's namespace field was changed from "URL" to "absolute URI" because relative references in a namespace are deprecated by XML, and the base URI to use for resolving them in the context of an OpenAPI Description is unclear. However, XML namespaces can include fragments, and the correct term is "non-relative URI" rather than "absolute URI" which forbids fragments. This change includes additional guidance on how XML usage and the requirements of this specification do not quite align.
Be very explicit that discriminator MUST NOT change the validation outcome, and explain the implication for the "allOf" use case.
and don't convert to JSON
…check-in Run tests with YAML metaschemas
3.0.4: set release date
3.0.4 set release date
Release v3.0.4
miqui
previously approved these changes
Oct 24, 2024
lornajane
previously approved these changes
Oct 24, 2024
earth2marsh
previously approved these changes
Oct 24, 2024
ralfhandl
dismissed stale reviews from earth2marsh, lornajane, and miqui
October 24, 2024 16:24
The base branch was changed.
earth2marsh
approved these changes
Oct 24, 2024
lornajane
approved these changes
Oct 24, 2024
miqui
approved these changes
Oct 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sync with main and set release date