-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Closed
Conversation
This file contains hidden or 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
Fix 3.0.4 .gitignore
Co-authored-by: Ralf Handl <[email protected]>
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
Fix "it" -> "its" typo
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)
Co-authored-by: Mike Kistler <[email protected]>
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.
Co-authored-by: Ralf Handl <[email protected]>
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.
Co-authored-by: Ralf Handl <[email protected]>
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
3.0.4: tables cleanup & markdownlint
…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
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.
This is a dummy PR showing the differences between
main
andv3.0.4-dev
after mergingDo not merge!