Precision and Scale for Decimal Values

[chapmanjw]

For decimal values, I have a use-case with minimum and maximum constraints on precision and/or scale. Is there an existing way to express maximum/minimum precision and scale?

I am familiar with multipleOf where a specific scale can be defined, for example:

{ "multipleOf":0.01 }

For my particular use-case, this only works when the min/max scale is the same (i.e. 2 in this case).

However, I don't see a way to express these constrains when the min/max scale values are different, such as a min scale of 2 and a max scale of 4 (where 1.11, 1.111, and 1.1111 are all valid values).

Additionally, I don't see a way to express precision.

Is there a way to accomplish min/max scale and precision given currently supported syntax?

If not, could these constraints be consider for a future draft?

• precision, maxPrecision, minPrecision
• scale, maxScale, minScale

[johandorland]

This sounds like a niche usecase to me. To accommodate these kind of use cases $vocabulary was introduced in 2019-09. I don't think we should bloat the core spec with these kind of features.

[chapmanjw]

This sounds like a niche usecase to me. To accommodate these kind of use cases $vocabulary was introduced in 2019-09. I don't think we should bloat the core spec with these kind of features.

I could see that for the scale case, but what about precision? Precision seems to be a fairly standard use-case for schemas...

[awwright]

@chapmanjw Is this related to json-schema-org/json-schema-spec#152?
I'm having trouble following you, you listed 1.111 twice in your example. What would be some code I could use to validate this (reading the JSON as a string, if you need to)?

[chapmanjw]

@chapmanjw Is this related to json-schema-org/json-schema-spec#152?
I'm having trouble following you, you listed 1.111 twice in your example. What would be some code I could use to validate this (reading the JSON as a string, if you need to)?

Updated the post, had meant to show an example where min scale is 2 and max scale is 4, thus 1.11, 1.111, and 1.1111. And in this example, 1.1 would not be valid.

[awwright]

@chapmanjw Can you elaborate more on why "multipleOf": 0.0001 doesn't satisfy you? What's a reason you'd want to make 1.1 invalid?

[chapmanjw]

@chapmanjw Can you elaborate more on why "multipleOf": 0.0001 doesn't satisfy you? What's a reason you'd want to make 1.1 invalid?

@awwright I am working on taking certain existing schemas defined in Ion and converting them to JSON Schema to enable use of these schemas in JSON-based REST APIs.

To the degree possible, I am looking for JSON Schema equivalents of the features supported by the Ion-based schema. For scale, that schema supports min / max constrains (similar to to the scale range in Ion Schema - Scale).

"multipleOf": 0.0001 certainly covers the maxScale use-cases. If, however, there is value for JSON Schema to address scale more specifically, it may make sense to cover both sides.

If there remains no equivalency for minScale in JSON Schema, that constraint would likely get dropped altogether during conversion. And internally handle padding 0s to the decimal values when necessary to pass the validation of the Ion-based schema.

[chapmanjw]

@chapmanjw Is this related to json-schema-org/json-schema-spec#152?

@awwright The use-case for precision in this schema conversion is exactly the same as the range of precision defined in Ion Schema Precision. It is the minimum or maximum total number of digits in the numeric value. There isn't any scientific notation concern for this use-case.

The common instances in the Ion-based schemas that I am converting use precision as a method of indicating the min/max length of the number as if it were a string.

As with the scale case, I am looking to ensure each of these features of the Ion-based schema are covered so that any future use does not break the conversion or result in invalid payloads due to improperly describing the requirements.

Until a JSON Schema equivalency of precision exists, these properties would likely need to be expressed as strings with a format or with a regex pattern.

[awwright]

I'm taking a little bit to read up on Ion, this is the first I've heard of it.

Off-hand and personally, it doesn't seem to me this is a property worth porting or converting between. The vast majority of JSON Schema validators would not be able to validate a property like this. Which is not much of a problem, they would just have to throw an error if it's used in a schema. I imagine usage of such a keyword wouldn't see much adoption if this was the case.

[chapmanjw]

@awwright For precision, scale, or both?

[hrennau]

Gentlemen - we contemplate the tip of an iceberg: JSON Schema does not yet support assertions, constraints in the form of expressions. I suggest to look at the problem at hand before the background of the following paragraph from the specification of SHACL, the new validation language for RDF

"Part 1 of this specification introduced features that are built into the Core of SHACL. The goal of this Core is to provide a high-level vocabulary for common use cases to describe shapes. However, SHACL also provides mechanisms to go beyond the Core vocabulary and represent constraints with greater flexibility. These mechanisms, called SHACL-SPARQL, are described in the following sections. "

https://www.w3.org/TR/shacl/#sparql-constraints

• immediately before this anchor, as an introduction of part 2

I am going to open an issue addressing this very general question.

[handrews]

I'm with @johandorland . This sort of relative niche case (totally valid but not incredibly common) is exactly why we added support for modular vocabularies. @chapmanjw as more implementations of draft 2019-09 or later become available, I'd suggest that you create a vocabulary to address Ion-specific issues, or perhaps just floating point issues.

@awwright @Relequestual do either of you see this as likely to be added to the Validation spec? We need a process for deciding when to close requests on the grounds that they should be handled by 3rd-party vocabularies.

[handrews]

...although I do agree that there's a stronger case for a precision keyword. Although in the event that a floating point number is parsed into a slightly different representation internally, the JSON Schema keyword would be applied to the parsed value. I think this is why most people who want fixed point decimal values encode them in strings.

While float/decimal issues are common in some areas of programming, they haven't come up all that often with JSON Schema. And when they have, they tend to be around string-based solutions anyway.

[awwright]

I'm still having trouble figuring out what minScale is supposed to do. Why should 1.1 be invalid, but 1.11 be valid? Am I reading that right?

I'd like to see an "in the wild" use case (some sort of testimony that this solves a real-world problem), and implementation that solves that problem.

[sbroekhuis]

I'm still having trouble figuring out what minScale is supposed to do. Why should 1.1 be invalid, but 1.11 be valid? Am I reading that right?

While I understand that this can be solved by using string-based solutions as has been said, if you want a use case, forcing a minScale has a solution regarding significant figures.

The value 1.1 could have been any value 1.05 - 1.14 and was rounded, forcing 2 decimal precision would avoid this potentiation confusion.
Imagine a survey, they ask users to record temperature of something. Some participant writes 13.78, another writes 14 and another writes 13.9. Researchers can not assume 14 = 14.00 and are limited by the precision of that value or have to discard it.

[IMSoP]

Regarding use cases, consider a location expressed as decimal latitude and longitude, e.g. from a GPS source. The scale of each value corresponds to the precision of the location.

The co-ordinates 1.1, 1.1 indicate the location is somewhere within an ellipse roughly 11 kilometres in diameter; but 1.1000, 1.1000 indicate an ellipse of only about 11 metres diameter, centred on the same point. Specifying minScale: 4 would be a way to require this precision.

At the other extreme, 1.1000000, 1.1000000 implies a precision of a single centimetre; a maxScale might be used to require input not to include spurious precision.

---

However, I agree that there would be a challenge implementing this in practice: although JSON itself defines "numbers" in terms of their decimal representation, common practice is to decode them as a language-native type, usually floating point, before applying any validation. That means that most implementations simply can't tell the difference between 1.1 and 1.1000000.

This already makes multipleOf unreliable for non-integer values (see e.g. json-schema-org/json-schema-spec#312) and the common workaround is to use strings at the JSON layer, and parse them into an appropriate numeric type at a higher level.

That suggests this is yet another case that should be folded into #45: the scale and precision options would realistically be used when embedding numeric values in a JSON string.