Consider adding a way to configure how strict number-related constraints are with respect to the number type being validated

[popematt]

A valid_values number range will accept any type of number. (E.g. for valid_values: range::[0, 2] any of 1, 1.0, and 1e0 are valid.) However, the scale and precision constraints only accept decimal values, and the proposed ieee754_float constraint only accepts float values.

An ISL user may wish to restrict the range of numerical values using these constraints without actually limiting the value to a specific type. (This is particularly an issue when up-converting from JSON to Ion—some values that are equivalent in JSON are interpreted as different types in Ion.)

To solve this sort of use case, it may be useful to have a way to configure how numbers are validated. Here are a strawman proposal to explain what I mean.

Idea 1

In the header, we can have a field to configure which "number mode" is to be used. This "number mode" would be used for the entire schema document, and they configure how the

schema_header::{
  number_mode: default // one of 'default', 'strict', 'relaxed'
}

• strict – number ranges are strongly typed; numeric constraints are strict about type
• default – current behavior: number ranges allow any number type; numeric constraints are strict about type
• relaxed – number ranges allow any number type; numeric constraints apply to all number types

Examples:

Constraint	Value	number_mode: strict	number_mode: default	number_mode: relaxed
valid_values: range::[1, 2]	1	valid	valid	valid
valid_values: range::[1, 2]	1.0	invalid value	valid	valid
valid_values: range::[1, 2]	1e0	invalid value	valid	valid
valid_values: range::[1, 2.0]	1	invalid schema	valid	valid
ieee754_float: binary16	1	invalid value	invalid value	valid
ieee754_float: binary16	1.0	invalid value	invalid value	valid
ieee754_float: binary16	1e0	valid	valid	valid

Idea 2

We could add a modifier to all of the numeric constraints that specifies that the type of number shouldn't be taken into account—only the mathematical value of the number. For example, ieee754_float: coerce_to_float::binary16 would mean that the value should be converted to a numerically equivalent float before checking if the value satisfies the constraint.

Number ranges could be be modified using a strict:: modifier so that they must have endpoints that are the same type and they only accept values of that type.

Open Questions

What happens when a number value doesn't have an exact representation or has more than one representation in some other number type? Intuitively, we might expect that 1 could be coerced to 1d0 or 1e0, but it's not as clear cut for 100. Would 100 be coerced as 1d2 or 1.00d2, or would the implementation try to determine if any possible representation was valid (e.g. choose a precision that is known to be valid from all possible "faithful" representations of the original value)?