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.