Skip to content
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 391 commits into from
Oct 24, 2024
Merged

3.1.1 set release date #4157

merged 391 commits into from
Oct 24, 2024

Conversation

ralfhandl
Copy link
Contributor

Sync with main and set release date

handrews and others added 30 commits June 11, 2024 11:04
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.
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]>
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.
@ralfhandl ralfhandl requested review from a team as code owners October 24, 2024 16:22
miqui
miqui previously approved these changes Oct 24, 2024
lornajane
lornajane previously approved these changes Oct 24, 2024
earth2marsh
earth2marsh previously approved these changes Oct 24, 2024
@ralfhandl ralfhandl changed the base branch from main to v3.1.1-dev October 24, 2024 16:24
@ralfhandl ralfhandl dismissed stale reviews from earth2marsh, lornajane, and miqui October 24, 2024 16:24

The base branch was changed.

@lornajane lornajane self-requested a review October 24, 2024 16:24
@miqui miqui merged commit 3deff43 into OAI:v3.1.1-dev Oct 24, 2024
2 checks passed
@ralfhandl ralfhandl deleted the 3.1.1-set-release-date branch October 24, 2024 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants