Describe parameters uniformly with location #651
Conversation
…s/case in description.
…s/case in description. Instead of using parameter *types* (which is not defined) and parameter *locations*, just used *location* uniformly; *parameter type* should only refer to the parameterType field, to avoid confusion. Use same order and values/case in the list of locations as in the description's allowed values for `in`.
Do not use the term "parameter type to refer to parameter *locations* (#parameterIn), just used *location* uniformly. Parameter type should only refer to the `type` field (`p#arameterType`) Use same order and values/case in the list as in the description and allowed values for `in`.
|
Fixes #663 |
|
@DavidBiesack - as the change goes, it should be against the new 3.0 branch. Right now, changes that would potentially go into 2.0 would either be typo fixes, 'bug fixes' (faulty examples for example) or critical clarifications, and this doesn't fall under any of these. As for uniformity, this does have room in 3.0. |
|
By "new 3.0 branch" do you mean OpenAPI.next ? I do not see a branch named "3.0" on https://github.com/OAI/OpenAPI-Specification/branches/active (I think I need to follow this process to change the PR to OpenAPI.next.) |
|
Yeah, that's what I meant. Submitting a PR against a different branch should be simple, but you'd need to submit it against a different document too. |
|
will do. |
|
@DavidBiesack - I don't recall if you submitted a new PR, but I'll close this one for now. |
|
I just submitted a new pull request with basically the same content against the correct branch: #923. |
Do not use the term "parameter type* to refer to parameter locations (
#parameterIn), just used location uniformly. Parameter type should only refer to thetypefield (#parameterType)Use same order and values/case in the list as in the description and allowed values for
in.