Skip to content

Conversation

@karenetheridge
Copy link
Member

@karenetheridge karenetheridge commented Nov 15, 2025

Various fixes and wording clarifications to the sections discussing parameters.

  • schema changes are included in this pull request
@karenetheridge karenetheridge requested review from a team as code owners November 15, 2025 22:47
@karenetheridge karenetheridge marked this pull request as draft November 15, 2025 22:47
@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch 3 times, most recently from 490500a to 2eed149 Compare November 15, 2025 23:29
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.

@karenetheridge thanks for continuing to work through all of these details! Some good catches here. I hope you don't mind me commenting on the draft as it sounds like you are adding more rather than likely to change what you have already posted. Let me know if you would prefer me to wait in the future.

I have a few questions and possible suggestions, and one very reluctant "it's not what I would do but it's what was decided" objection.

#### Fixed Fields

The rules for serialization of the parameter are specified in one of two ways.
The rules for serialization and deserialization of the parameter are specified in one of two ways.
Copy link
Member

Choose a reason for hiding this comment

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

I think in other places we have used "serialization and parsing" or "parsing and serialization." Do you think "deserialization" is a better term here? Is there a distinction between that and "parsing"? I have no idea what the answer is, I either copied "parsing" or picked it without much thought, so I'm open to changing it as long as we're consistent.

Copy link
Member Author

Choose a reason for hiding this comment

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

I searched the document and found that "deserialize" was used more often than "parse". I've standardized on the former in my implementation (after waffling a few times) as I think the symmetry makes more sense. Also I think "parse" is a little more vague -- you parse a string for any number of reasons, but what we're really doing here when we parse a parameter string is deserializing it into the json document model so we can then validate it against a json schema, or pass it to the user application in a format closer to its final form.

Copy link
Member Author

Choose a reason for hiding this comment

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

I searched the document and found that "deserialize" was used more often than "parse".

I doublechecked this assertion and it's false. We talk a lot about "parsing an OAD", and that's definitely the correct language there, but we say both "parse a parameter" and "deserialize a parameter".

I think I still prefer "deserialize" for its extra specificity though, when it is applicable -- an OAD is parsed to interpret its rules, and parts of an HTTP message are deserialized to be applied against the OAD rules.

Copy link
Member

Choose a reason for hiding this comment

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

If we're going to switch that terminology, I would rather discuss it in its own GitHub discussion and come to something resembling a consensus, and then make that change across the document. We have enough consistency problems without doing this piecemeal. I would feel the same way about changing any existing "deserialize" wording. Let's make an intentional, group-approved choice of terminology and then implement it. But in this PR, let's keep the exising terminology.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not changing terminology; it's adding it -- the main intent here is to make clear that parameter declarations are used both in serializing, and in parsing/deserializing. I am mostly indifferent as to which of these two terms are used, but the point is that there is more going on than just serializing.

this was added in commit 9739dfe, but now that the leading "?" has been
removed, this is no longer needed
@karenetheridge
Copy link
Member Author

Force-pushing a new version after checking all commits; more test cases have been added for the schema changes.

@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch from 6050bd6 to 423d8d3 Compare January 27, 2026 00:40
@karenetheridge karenetheridge marked this pull request as ready for review January 27, 2026 00:40
@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch from 423d8d3 to 1372357 Compare January 27, 2026 01:02
@karenetheridge
Copy link
Member Author

As this PR contains some fixes to things that are incorrect, IMO those commits at least should be backported to 3.2 and 3.1.

@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch 3 times, most recently from 185f7d4 to 6603f70 Compare January 27, 2026 01:52
miqui
miqui previously approved these changes Jan 27, 2026
namely: in=path, in=query, in=cookie+style=form,
but not in=header, in=querystring or in=cookie+style=cookie
and not in encoding objects where contentType is used (none of style, explode,
allowReserved are present)

this brings in some work that didn't get merged in OAI#4904
..and also fixes a bad $ref URI
@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch from fc13271 to 5d3944f Compare January 30, 2026 23:48
@karenetheridge karenetheridge requested a review from miqui January 30, 2026 23:49
… objects

- explode defaults were wrong for in: cookie, style: cookie, and for encoding object
- allowReserved defaults were wrong for encoding object

in parameter objects:
- explode: always false for "in: path", "in: header"
- explode: always true for "in: cookie" (both "style: form" and "style: cookie"
  default to "explode: true")
- explode: only true for "in: query" when "style: form" (the default style for
  this location)

in encoding objects:
- style: default is "form", but only when "explode" or "allowReserved" are present
- explode: default is true when "style: form" (the default style) and otherwise
  false, and not included at all unless "style" or "allowReserved" are present
- allowReserved: default is false, but only when "style" or "explode" are present

that is: when none of style, explode or allowReserved are present, "contentType"
is used (or a default is calculated), so none of style, explode or allowReserved
shall have default values
…ll defaults omitted

tested with:

$ openapi-validate --with-defaults tests/schema/pass/style-defaults.yaml
{
  "defaults" : {
    "/components/mediaTypes/encoding_object_defaults/encoding/allowReserved/explode" : true,
    "/components/mediaTypes/encoding_object_defaults/encoding/allowReserved/style" : "form",
    "/components/mediaTypes/encoding_object_defaults/encoding/explode/allowReserved" : false,
    "/components/mediaTypes/encoding_object_defaults/encoding/explode/style" : "form",
    "/components/mediaTypes/encoding_object_defaults/encoding/style_form/allowReserved" : false,
    "/components/mediaTypes/encoding_object_defaults/encoding/style_form/explode" : true,
    "/components/mediaTypes/encoding_object_defaults/encoding/style_spaceDelimited/allowReserved" : false,
    "/components/mediaTypes/encoding_object_defaults/encoding/style_spaceDelimited/explode" : false,
    "/components/parameters/cookie_cookie/deprecated" : false,
    "/components/parameters/cookie_cookie/explode" : true,
    "/components/parameters/cookie_cookie/required" : false,
    "/components/parameters/cookie_form/allowReserved" : false,
    "/components/parameters/cookie_form/deprecated" : false,
    "/components/parameters/cookie_form/explode" : true,
    "/components/parameters/cookie_form/required" : false,
    "/components/parameters/cookie_form/style" : "form",
    "/components/parameters/cookie_media_type/deprecated" : false,
    "/components/parameters/cookie_media_type/required" : false,
    "/components/parameters/header/allowReserved" : false,
    "/components/parameters/header/deprecated" : false,
    "/components/parameters/header/explode" : false,
    "/components/parameters/header/style" : "simple",
    "/components/parameters/path_label/allowReserved" : false,
    "/components/parameters/path_label/deprecated" : false,
    "/components/parameters/path_label/explode" : false,
    "/components/parameters/path_matrix/allowReserved" : false,
    "/components/parameters/path_matrix/deprecated" : false,
    "/components/parameters/path_matrix/explode" : false,
    "/components/parameters/path_media_type/deprecated" : false,
    "/components/parameters/path_simple/allowReserved" : false,
    "/components/parameters/path_simple/deprecated" : false,
    "/components/parameters/path_simple/explode" : false,
    "/components/parameters/path_simple/style" : "simple",
    "/components/parameters/query_deepObject/allowEmptyValue" : false,
    "/components/parameters/query_deepObject/allowReserved" : false,
    "/components/parameters/query_deepObject/deprecated" : false,
    "/components/parameters/query_deepObject/explode" : false,
    "/components/parameters/query_deepObject/required" : false,
    "/components/parameters/query_form/allowEmptyValue" : false,
    "/components/parameters/query_form/allowReserved" : false,
    "/components/parameters/query_form/deprecated" : false,
    "/components/parameters/query_form/explode" : true,
    "/components/parameters/query_form/required" : false,
    "/components/parameters/query_form/style" : "form",
    "/components/parameters/query_media_type/allowEmptyValue" : false,
    "/components/parameters/query_media_type/deprecated" : false,
    "/components/parameters/query_media_type/required" : false,
    "/components/parameters/query_pipeDelimited/allowEmptyValue" : false,
    "/components/parameters/query_pipeDelimited/allowReserved" : false,
    "/components/parameters/query_pipeDelimited/deprecated" : false,
    "/components/parameters/query_pipeDelimited/explode" : false,
    "/components/parameters/query_pipeDelimited/required" : false,
    "/components/parameters/query_spaceDelimited/allowEmptyValue" : false,
    "/components/parameters/query_spaceDelimited/allowReserved" : false,
    "/components/parameters/query_spaceDelimited/deprecated" : false,
    "/components/parameters/query_spaceDelimited/explode" : false,
    "/components/parameters/query_spaceDelimited/required" : false,
    "/jsonSchemaDialect" : "https://spec.openapis.org/oas/3.2/dialect/WORK-IN-PROGRESS",
    "/servers" : [
      {
        "url" : "/"
      }
    ]
  },
  "valid" : true
}

(executable is part of https://github.com/karenetheridge/OpenAPI-Modern)
..and remove example that is specific to a particular style, explode and
schema type configuration
@karenetheridge karenetheridge force-pushed the ether/3.3-parameter-styles-more branch from 5d3944f to e332c52 Compare January 31, 2026 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

4 participants