Reconsider 'range' for string parameters

[awoods]

Related to comments: #13 (comment)

The range currently defined for string parameters can be somewhat unintuitive:

the range specifies the maximum length of the string as an integer number of characters, not bytes

This issue is to discuss potentially more suitable definitions for a string's range.

[awoods]

As one datapoint, JSON allows for "ranges" to include:

• maxLength and minLength
• regex pattern
• predefined formats

https://json-schema.org/understanding-json-schema/reference/string.html

[sprater]

Regex might be a good catch-all range, as both length and format can be defined as regex patterns.

[botimer]

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.

• When type is integer, minValue and maxValue are integers (+ fuller details, inclusive/exclusive, etc.)
• When type is string, minLength and maxLength are integers ... format is an ES6-compatible regular expression that must be matched by any value ...
• When type is enum, allowedValues is an array of acceptable strings ...
• When type is boolean, no constraints are applicable and must not be included

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.

[awoods]

Resolved with: 8f33d76#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R46