v3.1-dev: sync with dev #5036
Merged
v3.1-dev: sync with dev #5036
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
Since we are testing with a placeholder, we need to match the placeholder. This will unfortunately need to be different on each new release line branch, so let's separate this test case into its own file.
3.2: try to fix automation for jsonSchemaDialect.yaml
We require `content` but failed to require it to be non-empty, even though a request body without a body does not make any sense.
3.2 merge dev
v3.2: (port of #4614) Clarify that Request Body Objects need a body
v3.2-dev: update from dev
These media types solve our long-standing problems with modeling HTTP Link headers. We do not need to define anything beyond noting how to use them media types in a Media Type Ojbect.
We allow multiple `contentType` values in the Encoding Object, but do not provide any guidance on how to determine which to use when performing the encoding. This adds such guidance.
This adds the Media Type Object's encoding field to the Encoding Object to support nested multipart documents. It only requires one level of nesting, but allows implementations to support more.
v3.2: improve wording for servers object and url
v3.2-dev: update from dev
We don't really need the stuff about character encodings, as it was there because I was confused about something else. Also minimize the explanation of the change.
Co-authored-by: Lorna Jane Mitchell <github@lornajane.net>
v3.2-dev: update from dev
Examples at different levels serve different purposes, and it is not clear what is meant by "overriding." Removing this will allow tools to determine the most appropriate example(s) to show in a given context.
v3.2: Add support for application/linkset[+json]
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
Almost all of our guidance on parsing and resolving OADs is under the section "OpenAPI Description Structure", _except_ for the parts on resolving relative OAD URI and API URL references. Those two sections are further down, after a lengthy discussion of data types. This moves (without any changes except heading levels) those URI/URL resolution sections up with all of the other parsing guidance. I have placed them before the "Implicit Connections" section because those connections are "Implicit" in contrast to URI references, which are explicit. This puts all of the parsing guidance in one place, and properly contextualizes "Implicit Connections" instead of introducing them before the far-more-common URI connections.
This clarifies that variables in both path and server URL templates MUST be unique. This is justified as compatible with our minor release policy on the following grounds: * Due to Parameter Object `name` + `in` constraints and the Server Object's `variables` field being a map, each variable can only map to one paramater or server variable (although the "one" paramater might be defined separately yet uniquely for each Operation). * The Path Templating section uses the phrase "Each template expression in the path MUST correspond to ***a*** path parameter" (emphasis added). * The Parameter Object uses similar language in the other direction: "If in is "path", the name field MUST correspond to ***a*** template expression". * The word "a" is interpreted to mean an unknown but unique thing in both directions. * The Server Object's `url` template has always been assumed to function in an analogous way to path templating.
This creates a "Working with Data" section that incorporates the existing "Data Types" section (with some section level adjustments) along with new guidance on mapping different kinds of data between serialized, data, and application forms. This terminology matches the terminology currently being considered for examples. The application form is largely out of scope for the OAS, and is mainly included to clarify this scope while acknowledging that the OAS may influence such things. Most of the new material is on parsing and serializing, briefly addressing JSON as the common case before going into detail on non-JSON data, with examples. This is where the requirements for schema and/or instance inspection/searching are listed. The only additional change is no longer mentioning the property schema in the Encoding Object, in part because with the new `multipart/mixed` support Encoding Objects can be used with arrays as well as objects.
Steps: - create sync branch from base branch - merge head branch into sync branch - restore src/* and tests/* from base branch - commit & push - create PR for merging sync branch into base branch
Add package dependency Add config file for linkspector Include in validate-markdown npm script Include in validate-markdown.yaml workflow Check other markdown files, fix link in README.md
copy lander of preceding version and adjust version in lander
main: use Linkspector action in validate-markdown workflow
…kyll-lander main: create jekyll lander if necessary
docs: Add 3.3.x spec and schemas reference to PR template
ralfhandl
approved these changes
Oct 15, 2025
|
Only the expected files changed. |
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.
Merge relevant changes from
devintov3.1-dev.