-
Notifications
You must be signed in to change notification settings - Fork 12
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
Reconsider 'range' for string parameters #23
Comments
As one datapoint, JSON allows for "ranges" to include:
https://json-schema.org/understanding-json-schema/reference/string.html |
Regex might be a good catch-all range, as both length and format can be defined as regex patterns. |
It seems to me that flattening the schema and using string-encoded data here is medicine worse than the disease. I think the more intuitive approach is to expand the schema for parameter definitions to cover "constraints" as an optional, composite value with a set of valid properties dependent on the type. In such case, such definitions would be more obvious to humans and the handling/validation code will likely be less error prone than a bunch of conditional string parsing on the same overloaded field.
I think there is minimal value in requiring JSON-compatible identifiers and quoting but stopping short of accepting that some elements here really are structured or typed differently. A couple of key-value properties and an array property don't offend me, but string smashing does. |
Related to comments: #13 (comment)
The
range
currently defined for string parameters can be somewhat unintuitive:This issue is to discuss potentially more suitable definitions for a string's
range
.The text was updated successfully, but these errors were encountered: