Skip to content

fix wording on who supplies the default value for a server variable #1571

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 2 commits into from
May 8, 2018

Conversation

notEthan
Copy link
Contributor

@notEthan notEthan commented May 4, 2018

the server variable default is supplied in the OpenAPI document, not by the consumer.

not sure the best wording to fix it, but the current wording is incorrect, I believe.

@webron
Copy link
Member

webron commented May 4, 2018

It's correct, but perhaps incoherent. The idea is that the consumer of the document must use the default value for a server variable, unlike the default value of a parameter, for example.

@notEthan
Copy link
Contributor Author

notEthan commented May 4, 2018

the consumer of the document must use the default value

sure, the consumer must use it, as you say. but that's completely different than providing the value - that is not done by the consumer but by the document.

I think we're arguing semantics at that point though, and since you describe it as perhaps incoherent, maybe can agree that it should be changed? and if so, what would be a better wording?

@darrelmiller
Copy link
Member

darrelmiller commented May 7, 2018

Text will be reviewed to try and add some more clarity. @OAI/tsc doesn't feel the current PR accurately conveys the intent.

@earth2marsh
Copy link
Member

earth2marsh commented May 7, 2018

Suggest something like [edited]:
The default value to use for substitution, which SHALL be sent if an alternate value is not supplied. Note this behavior is different than the Schema Object's treatment of default values, because in those cases parameter values are optional.

@earth2marsh
Copy link
Member

earth2marsh commented May 7, 2018

We discussed the language proposed in my last comment on the TSC call today and had verbal approvals for the edited version above. @notEthan would you like to incorporate and re-submit?

@webron
Copy link
Member

webron commented May 8, 2018

@notEthan I went ahead and modified the PR with the proposed changes as we want to push out a new version. We can revisit it if still needed in 3.0.3.

@webron webron merged commit cb5376c into OAI:v3.0.2-dev May 8, 2018
@notEthan
Copy link
Contributor Author

notEthan commented May 8, 2018

thanks @webron, looks good to me

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.

4 participants