Skip to content

Dummy PR for merging 3.0.4 into main #4075

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

Closed
wants to merge 306 commits into from

Conversation

ralfhandl
Copy link
Contributor

This is a dummy PR showing the differences between main and v3.0.4-dev after merging

Do not merge!

handrews and others added 30 commits May 7, 2024 10:23
Clarify constraints on Parameter Object fields (3.0.4)
Define "undefined" and "implementation-defined" (3.0.4)
…sitive

Backport case insensitivity note for security schemes to 3.0.4
and correct expansion of "auth"
This was missed in the 3.0.4 PR for this change, but caught in
the 3.1.1 and 3.2.0 versions.
…itivity-note

Link for case insensitivity of auth scheme
This clarifies the meaning of `allowEmptyValue` as discussed in
today'd TDC call.  It is intended to indicate an agreement between
the client and server to use zero-length string values as an
indicator of unused fields.
As discovered through the OASComply project, certain referencing
scenarios are ambiguous, with different authorities holding
contradictory interpretations regarding whether and how they are
to be supported.  As a result, it is impossible to define
compliance, as all of the interpretations can be argued to be
"correct" in some sense.

This change excludes some particularly challenging scenarios from
compliance testing by making their behavior explicitly
implementation-defined.  This has several benefits:

* No current implementation is rendered non-compliant
* No currently usable OAD is rendered invalid
* New implementers need not put effort into handling these scenarios
* User expectations are set to _not_ expect consistent behavior
* Linters can write a rule to match these expectations
* Everyone is guided towards straightforwad best practices

Includes substantially better wording from ralfhandl from
review comments for the 3.1.1 version of this change.

Co-authored-by: Ralf Handl <[email protected]>
This moves some guidance up to the fixed fields section where
it is more obvious, and explicitly designates other configurations
as having undefined behavior.
This creates subsections to organize the different topics, pulls
key guidance out of the examples and up into those sections,
and provides clarification on the ambiguity of names and URIs.
Clarify allowEmptyValue -> disregard empty values (3.0.4)
Clarify interoperable parsing expectations (3.0.4 port of OAI#3732)
Clarifies that there can be multiple complete OpenAPI documents,
only one of which is an entry OpenAPI document.
Clarify entry/complete document terminology (3.0.4)
Clarify discriminator "*Of" and "mapping" usage (3.0.4)
This acknowledges the ambiguity in the key and value syntax of the
Link Object's `parameter` field, and provides a bit of guidance
on how to implement it.  Sadly it is not possible to fully solve
in a point release.
This aligns allowReserved with style by similarly correlating it
with RFC6570 operators.  This will make it easier to write a more
in-depth explanation of the process in an appendix.
This is the one of several appendixes to be added to clarify
the most obscure details of Parameter Object and Encoding Object
serialization.

This clarifies the correspondence between OAS fields and RFC6570
operators, and acknowledges that some field values and combinations
do not have analogues.  It provides further guidance for how to
use RFC6570 implementations to support these configurations.

This includes a SHOULD directive regarding using RFC6570 expansion
with the non-RFC6570 styles, as the use of "explode" and
"allowReserved" does not otherwise make any sense.  It perhaps
could be a MUST.

Examples are included to show both typical usage, and how to
work around the lack of exact RFC6570 equivalences for certain
configurations.
Note that they are resolved in their rendered context.
RFC6570-based serialization will not go beyond what is specified
to unpack arrays and objects.
ralfhandl and others added 26 commits August 22, 2024 15:37
3.0.4: link to example on learn site
Define capital-O "Object" to make it clear why it is only occasionally
capitalized.

Use lowercase "with" in titles consistently (it was more common than
capitalized "With".  This is one of those rules that is different
depending on whose style guide you use- about half the major guides
say always lowercase, the other say always captial.  We were using
lowercase more often.

Also, fix "Working with Examples" to be a subsection of the
Example Object as otherwise it breaks the pattern of all of the
headings of its level being Object definitions.  I remember messing
with this a lot when I first posted that PR and either I just
missed this or I had some reason I have now forgotten to do it
this way.
"Object" definition, "with" in titles, fix level of "Working with Examples"
This is a slightly different change due to the different JSON Schema
draft being referenced.

Most notably, the older draft has a section on type applicability,
so there is an extra link here that is not present in 3.1.1.

Co-authored-by: Mike Kistler <[email protected]>
Port format / integer changes from 3.1.1
…-draft-wright-00

3.0.4: use same reference style for draft wright as OAI#4053
…rity

3.0.4: absent, empty, or incomplete security list
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