Skip to content

v3.2: Clarify template variable uniqueness #4791

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

Merged
merged 1 commit into from
Jul 18, 2025

Conversation

handrews
Copy link
Member

NOTE: This takes the opposite view as the thread in #4763 (comment) based on continued slack conversations where we dug deeper into the spec wording. Please see the note after the list as well:

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.

Note: I think this is reasonably solid, and no one has actually presented a use case or known use of duplicate fields, but it does rely on interpreting language in a very specific way. I am very much interested in whether people see this as a clarification or change, as my intent is for it to be a clarification.

  • schema changes are included in this pull request
  • schema changes are needed for this pull request but not done yet
  • no schema changes are needed for this pull request

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.
@handrews handrews added this to the v3.2.0 milestone Jul 17, 2025
@handrews handrews requested review from a team as code owners July 17, 2025 23:43
@handrews handrews added clarification requests to clarify, but not change, part of the spec request matching Matching requests to URL templates, media types, etc. labels Jul 17, 2025
@ralfhandl ralfhandl requested a review from a team July 18, 2025 07:23
Copy link
Contributor

@mikekistler mikekistler left a comment

Choose a reason for hiding this comment

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

Looks good. 👍

@ralfhandl ralfhandl merged commit 2c7432c into OAI:v3.2-dev Jul 18, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification requests to clarify, but not change, part of the spec request matching Matching requests to URL templates, media types, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants