v3.0.4(schema): Update empty security array constraint #4069
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 style=form examples (3.0.4)
This makes the relational requirements of `content` vs `schema` and associated fields more clear. The mutual exclusivity requirement is moved up to the top of the Fixed Fields section, and each table table is given a subsection clarifying its meaning. This makes it easier to follow the multi-table format, which is unusual within the OAS. The commentary on `example` and `examples` is moved to the section on `schema` and related parameters as it appears to only apply in that case.
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.
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
based on discussions * OAI#3938 (comment) * OAI#4007
jeremyfiel
force-pushed
the
feat/update-empty-security-array-constraint-3.0.x
branch
from
4a1b2e2 to
4d90c9b
Compare
|
@jeremyfiel could you please re-target this to main? We don't change the schemas on the branches (except by accident) |
|
Oof. Changing requires a new force push. I'll do it later today when I get a chance |
|
@jeremyfiel Thanks for providing this! Assuming this PR is to be merged after publication of 3.0.4 I've converted it to draft. |
ralfhandl
requested changes
Sep 5, 2024
| @@ -20,6 +20,7 @@ properties: | |||
| $ref: '#/definitions/Server' | |||
| security: | |||
| type: array | |||
| minItems: 1 | |||
There was a problem hiding this comment.
This contradicts what we say now in the spec
|
Closing for the same reasons that @lornajane articulated on the 3.1.1 version of this (although we look forward to incorporating this sort of idea in a different form in the future!):
|
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.
based on discussions
Clarification about the meaning of an empty security array #3938 (comment)
Clarify
security; state what[]means #4007