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

Release v3.1.1 #4082

Draft
wants to merge 330 commits into
base: main
Choose a base branch
from
Draft

Release v3.1.1 #4082

wants to merge 330 commits into from

Conversation

handrews and others added 30 commits April 22, 2024 08:13
These should have the parameter name in the resulting string (see issue #3737).
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
Limit interoperable parsing expectations (avoid type conflicts)
Be more clear about `format` support (3.1.1)
The "undefined" wording was chosen to allow implementations
that make a good-faith effort to accommodate non-string values
to remain compliant.  However, new implementations are not
expected to implement any sort of type coersion, and this
guides API designers away from that expectation.
The previous wording could be read to only restrict what sort
of request bodies could use an Encoding Object, while allowing that
it could be used with other entities that use a Media Type Object.

This emphasizes that it is only relevant to Request Body Objects,
and within that, only for specific media types.
The OAS does not define how to avoid collisions between parameter
values and style delimiters.  Mostly, this is straightforward,
but the need to URL encode space characters introduces extra
confusion.  Make it clear that managing this occurs outside
of the use of style, and is the responsibility of users.
JSON Schema draft 2020-12 includes numerous keywords that require
parsing the entire document prior to deeming a reference unresolvable.
This makes that more clear and outlines several approaches.

The practice of embedding OpenAPI fragments in other formats is
deemed to have implementation-defined (non-interoperable) behavior,
as the potential complications that might arise are not predictable.
Also, remove the example that goes against the advice in the
updated binary-handling section.
Clarify how to model binary data in 3.1
Correctly escape example operationRef URLs (3.1.1 port of #3731)
Non-string discriminator values (3.1.1 port of #3728)
Clarify spaceDelimited with spaces in values (3.1.1 port of #3723)
Clarify wording on encoding field (3.1.1 port of #3724)
If no Encoding Object is provided, the behavior is the same as
an empty Encoding Object, as none of its fields are required.
Also make the translation from 3.0 binary modeling a subsection,
as otherwise the line about streaming either feels randomly inserted
into the middle of the section, or feels disconnected when placed
after the conversion table.
@baywet
Copy link
Contributor

baywet commented Oct 14, 2024

I might have missed something here. But wanted to make sure this wasn't forgotten before the release goes out. This release still contains plenty of links to json schema draft 00 from ben hutton. I thought we meant to correct them to draft 12?

@handrews
Copy link
Member

@baywet See issue #3934 and #4127 – this isn't something we change in a patch release (same for superseded RFCs, see issue #3800 )

@handrews
Copy link
Member

@baywet

I thought we meant to correct them to draft 12?

That draft is draft 2020-12. The IETF draft numbers and the metaschema dates are not related.

@handrews
Copy link
Member

@ross-paypay

Really looking forward to Generic Data Structures getting added to the spec.

Is there any ETA on when this will get merged?

As this is a proper patch release, all of the "changes" here actually also apply to 3.1.0. We're just making them more clear. The generic data structures thing is something some JSON Schema folks figured out you can do with $dynamicRef, it's not even something we came up with. So feel free to lobby your tooling vendor to support them for 3.1 in general, not just 3.1.1.

As for merging, I'm hoping we'll put 3.0.4 and 3.1.1 in the final week-long voting period in the TDC call today.

darrelmiller
darrelmiller previously approved these changes Oct 17, 2024
miqui
miqui previously approved these changes Oct 17, 2024
@miqui
Copy link
Contributor

miqui commented Oct 17, 2024

Looks good to me (approved)

lornajane
lornajane previously approved these changes Oct 17, 2024
earth2marsh
earth2marsh previously approved these changes Oct 17, 2024
Copy link
Member

@earth2marsh earth2marsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great--thanks for all the hard work!

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.