-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Comments
It kind of goes against the enum being there so I don't think so. |
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 |
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.. |
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? |
What is there to fix? |
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. |
@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. |
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. |
Thanks @tedepstein @philsturgeon @handrews for the clarification |
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
The text was updated successfully, but these errors were encountered: