Skip to content
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

Enum with maxlength/minlength #2153

Closed
shwetashukla opened this issue Feb 21, 2020 · 9 comments
Closed

Enum with maxlength/minlength #2153

shwetashukla opened this issue Feb 21, 2020 · 9 comments

Comments

@shwetashukla
Copy link

shwetashukla commented Feb 21, 2020

Hi

Should maxlength/minlength be valid attributes with enum?

"status": {
"type": "string",
"description": "pet status in the store",
"maxLength": 12,
"enum": [
"available",
"pending",
"sold"
]
}

Thanks
Shweta

@erunion
Copy link

erunion commented Feb 21, 2020

It kind of goes against the enum being there so I don't think so.

@shwetashukla
Copy link
Author

Yes you are correct , but is it specified in the specification . When i run the open api document against any validator it doesn't show any error

@webron
Copy link
Member

webron commented Feb 21, 2020

It's valid, it just doesn't really help much. If one of the enum values would be longer than 12 characters, that enum value will not be valid through validation..

@shwetashukla
Copy link
Author

Yup so should this be fixed in specification then so that all other dependent tools like validators and code generators can also update as per specification?

@webron
Copy link
Member

webron commented Feb 21, 2020

What is there to fix?

@philsturgeon
Copy link
Contributor

I cannot imagine what a fix would be @shwetashukla, but regardless, OpenAPI v3.1 Schema Object (where the enum property is described) is JSON Schema. Seeing as this is valid JSON Schema, there is nothing to fix in OpenAPI. The conversation could be had on the JSON Schema spec repo, but the same question exists: I don't know if there's anything in the spec to fix there either.

@handrews
Copy link
Member

@philsturgeon @shwetashukla I'll state definitively that there is nothing to fix here.

JSON Schema does not forbid apparently-nonsensical combinations of attributes. If you want to do that, a linter or a custom meta-schema is the appropriate place to decide what you want to forbid.

There are several reasons why this is allowed, but the most fundamental is that it keeps implementations simple. You just evaluate all of the keywords you have, with no need to keep track of which keywords conflict with which other keywords.

@tedepstein
Copy link
Contributor

Right. Put another way, each JSON Schema assertion has independent veto power. A value has to pass all of the assertions in order to be valid.

It's possible for a schema to include constraints that are redundant, overlapping, or even contradictory, making the schema unsatisfiable. But it's up to the schema designer, posssibly with the help of linters or other tools, to avoid these issues.

OpenAPI 3.1, currently in progress, aims to close the gap so that OpenAPI documents can use the full set of JSON Schema keywords. That's the direction, and we don't want to adopt any changes that would put OpenAPI out of step with JSON Schema. But there is an Alternative Schema proposal that would allow other schema languages to be used in OpenAPI. We could take up that proposal in a future version of the OpenAPI spec.

@shwetashukla , hopefully we've addressed your concern, so I'll close this issue for now. If you feel the issue isn't really resolved, please feel free to reopen the issue and provide further comments.

@shwetashukla
Copy link
Author

Thanks @tedepstein @philsturgeon @handrews for the clarification

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

No branches or pull requests

6 participants