Skip to content

Conversation

lornajane
Copy link
Contributor

@lornajane lornajane commented May 16, 2025

Opening this as a pull request purely as a good way to collaborate - DO NOT MERGE.

The content will be added to the github release.

@miqui
Copy link
Contributor

miqui commented May 20, 2025

@lornajane So far looks good to me.

@jeremyfiel
Copy link
Contributor

should add more detailed info on new keywords in MediaType object.

@lornajane
Copy link
Contributor Author

@jeremyfiel can you say something about what's missing? (I obviously don't know or it wouldn't be missing ...) I did just update with some of the changes from the last couple of weeks, but I don't think there is anything here that would match what you're asking for.

@handrews
Copy link
Member

handrews commented Jul 5, 2025

I'd like to propose a slightly different ordering to improve the storytelling around this release:

  1. Our marquee features are improved tagging and *sequential/streaming support, and the latter of those is part of a pretty comprehensive update to data modeling and representation.
  2. Expanded HTTP method support, self-identifying documents, and expanded OAuth support are our other major changes.
  3. Improving the details and rigor of servers, paths, runtime expressions, and responses are "quality-of-life" improvements, to quote a recent Slack conversation.

This would give us a flow more like the following:

3.2 Updates

Tags

Data Modeling and Representation

OAS v3.2 makes significant progress towards more consistent, modular, and extensible media type and parameter support, while also expanding the set of media types supported in response to both emerging and legacy use cases. In addition, we have removed ambiguity regarding how to present examples in a variety of complex scenarios.

Media Type Registry

Sequential and Streaming Media Types

Parameters and Headers

Multipart Media Types

XML

Code Generation

Example Object

Additional Major Additions

Note: This subsection ordering within this section makes sense to me, but I do not feel strongly about it.

Methods

Document Identification and Reference Resolution

Security

Smaller Improvements

Servers, Paths, and Runtime Expressions

Responses

Updated to New Versions of Other Standards

etc.

@lornajane
Copy link
Contributor Author

There's about 50% more spec change since I wrote this draft, re ordering definitely in our future! Thanks for the outline , I'll be trying to catch up this week

Copy link
Contributor

@ralfhandl ralfhandl left a comment

Choose a reason for hiding this comment

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

Nice!

@lornajane
Copy link
Contributor Author

Started adding the suggested structure (in 3 parts: digestible high level features, the masterpieces of data modeling, and then everything else), but I note that we don't have all the sections you mentioned @handrews , in particular:

  • media types registry, these are the release notes on the specification and the media types registry isn't in this document so they're not included. Hold that thought for the blog content though
  • code gen, I'm not sure what should go here
  • multipart handling, how did I get this far without adding it? I have no idea but I've put a placeholder for now!

@miqui
Copy link
Contributor

miqui commented Aug 17, 2025

@lornajane Nice job!! Looks GREAT to me.

@ralfhandl ralfhandl linked an issue Aug 18, 2025 that may be closed by this pull request
@lornajane lornajane requested a review from handrews August 23, 2025 11:14
@lornajane
Copy link
Contributor Author

This is chaos, I'll be restructuring to make much slimmer release notes, an upgrade guide for the learn site and an announcement blog post (with the option to drill in with blog posts on more topics). I don't have a lot of time for the next week or so but I'll push updates when I can - since I'll mostly be moving content around, feedback on this current version is still very helpful if you have any

Copy link
Contributor

@ralfhandl ralfhandl left a comment

Choose a reason for hiding this comment

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

Nice! Only minor suggestions.

Copy link
Member

@handrews handrews left a comment

Choose a reason for hiding this comment

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

@lornajane thanks for the continued great work! Here's more suggestions, please feel free to reword them further. I know I tend to include too much detail or make the language too specification-like for this.

@lornajane
Copy link
Contributor Author

Thank for all the brilliant reviews!! Split a bunch of the content out to become some new docs: OAI/learn.openapis.org#137

Copy link
Member

@karenetheridge karenetheridge left a comment

Choose a reason for hiding this comment

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

That was my final pass!

There were a few places where grammar could be improved, e.g. add missing articles, switch away from passive voice but I'll leave it to the experts for the final polish :)

- `parent` field to point to the tag that this tag is nested under. If you use `x-tagGroups`, adjust to use a tags hierarchy.
- `kind` field to allow a tag to be classified into a category such as navigation, or audience.
The `kind` field is free-form text, however there are some expected/conventional values such as `nav` (in line with the most common current usage as grouping for documentation output).
- A [registry](https://spec.openapis.org/registry/tag-kind/index.html) to establish conventions for values used in `kind`.
Copy link
Member

Choose a reason for hiding this comment

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

Pulled this out of the bullets as the registry isn't a new field.

Suggested change
- A [registry](https://spec.openapis.org/registry/tag-kind/index.html) to establish conventions for values used in `kind`.
And we've added a [registry](https://spec.openapis.org/registry/tag-kind/index.html) to establish conventions for values used in `kind`.

#### Support additional HTTP methods
- Support the new `query` method alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`.
Copy link
Member

Choose a reason for hiding this comment

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

Added "field" to distinguish the field name from the actual method name which is QUERY.

Suggested change
- Support the new `query` method alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`.
- Support the new `query` method field alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`.

- Support the new `query` method alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`.
QUERY is a [draft standard](https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-11.html) new HTTP method nearing final publication, which is designed to allow complex filtering query data to be sent in the body of a request when it doesn't fit in the query string.
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. you can add `LINK` under this field, but do NOT add `HEAD`; use the existing Operation Object `head` field.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. you can add `LINK` under this field, but do NOT add `HEAD`; use the existing Operation Object `head` field.
- Under an `additionalOperations` entry in a Path Item Object, use any other methods not listed as keys using the correct capitalization, e.g. you can add `LINK` under this field, but do NOT add `HEAD`; use the existing Operation Object `head` field.

QUERY is a [draft standard](https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-11.html) new HTTP method nearing final publication, which is designed to allow complex filtering query data to be sent in the body of a request when it doesn't fit in the query string.
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. you can add `LINK` under this field, but do NOT add `HEAD`; use the existing Operation Object `head` field.

The following example describes both QUERY and LINK methods for the `cakes/` endpoint:
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
The following example describes both QUERY and LINK methods for the `cakes/` endpoint:
The following example describes both QUERY and LINK methods for the `/cakes` endpoint:

- Support for additional HTTP methods

- Support the new `query` method alongside the existing `get`/`post`/`put`/`delete`/`options`/`head`/`patch`/`trace`.
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. `LINK`. Do NOT add `HEAD` under this, use the existing sibling `head`.
Copy link
Member

Choose a reason for hiding this comment

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

as in the main document:

Suggested change
- Under an `additionalOperations` entry in a Path, use any other methods not listed as keys using the correct capitalization, e.g. `LINK`. Do NOT add `HEAD` under this, use the existing sibling `head`.
- Under an `additionalOperations` entry in a Path Item Object, use any other methods not listed as keys using the correct capitalization, e.g. you can add `LINK` under this field, but do NOT add `HEAD`; use the existing Operation Object `head` field.

Copy link
Contributor

Choose a reason for hiding this comment

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

"and use the existing" instead of a
semicolon?

- Document identity and URL resolution

- Additional top-level field `$self` is added to allow users to define the base URI of the document, used to resolve relative references.
- More explanation and examples regarding URL resolution.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- More explanation and examples regarding URL resolution.
- More explanation and examples regarding URI resolution.

@lornajane
Copy link
Contributor Author

Thanks for all your input, the content became the release notes and also some documentation updates, so the pull requests is no longer needed

@lornajane lornajane closed this Sep 20, 2025
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.

Release notes for 3.2.0 and 3.1.2
7 participants