[BUG] Fixed Point Constraint (scale) is not validated by the json-schema

[jSchuetz88]

I'm not sure, whether it is an actual issue or an misunderstanding of the documentary from my side.

How: List of performed steps
The documentation for samm-c:scale states:

The scaling factor for a fixed point number. E.g., if a fixedpoint number is 123.04, the scaling factor is 2 (the number of digits after the decimal point). Must be given as xsd:positiveInteger.`

What: Actual result vs expected result
In my understanding, if I have for example

samm-c:integer "18"^^xsd:positiveInteger ;
samm-c:scale "3"^^xsd:positiveInteger .

the JSON schema should't validate a value with more than 3 digits after the decimal point?
e.g. "1000000.324454" should not be a valid value? The scale seems to be ignored within the json-schema.

Where: (e.g. component, version, url, your system info)

• generated json-schema by samm-cli-2.6.0.jar, but also tested with samm-cli-2.9.5.jar

[atextor]

Yes, this should be evaluated, I'd also consider it a bug.

[chris-volk]

Related: json-schema-org/json-schema-vocabularies#8

[Yauhenikapl]

Hi everyone,

After thoroughly investigating this issue, we have the following findings:

1. Limitations of JSON Schema for Fixed Precision in Numbers
   The JSON Schema does not natively support fixed precision checking for numbers of type Number. This limitation arises because JSON Schema's primary focus is on specifying types and constraints for JSON data, but it does not provide a built-in mechanism for enforcing precision directly on numeric types.
   You can find a list of possible types supported by JSON Schema here.

   One of the potential workarounds for this issue is leveraging the Range constraints (i.e., minimum and maximum) available for the Number type. This approach is commonly used in SDKs to define range constraints for numeric values. However, it falls short when trying to enforce a specific precision or the exact number of decimal places required to resolve this issue.

   For instance, while Range can limit the numerical value (e.g., 1.5 ≤ x ≤ 10.5), it cannot ensure that a number like 1.23 adheres to a precision constraint of exactly two decimal places. This inherent limitation leaves gaps in functionality for precise validation needs.

2. Regex Constraints for Strings Only
   Another approach we explored was using regular expressions (regex) for validating numeric precision. However, according to the JSON Schema specification, regular expressions are only applicable to the string type. This means we cannot directly use regex patterns to validate numbers or enforce numeric constraints within a JSON Schema.

   For example, while regex can be used to enforce patterns like "^\d{2}\.\d{2}$" for strings to ensure a format like XX.XX, this functionality is inapplicable to numeric values without converting them to strings first—a process that JSON Schema does not natively support.

Conclusion:
The current limitations in JSON Schema make it challenging to validate and enforce fixed precision for numeric types directly. While range constraints and regex are useful in specific scenarios, they cannot fully address the issue without additional custom logic or preprocessing outside of JSON Schema's built-in capabilities.

For now, I propose to close this issue and if someone can provide another way for resolving this issue, please write a comment and we will reopen this issue.

Thanks!

[jSchuetz88]

Thank you for the detailed answer and follow up. That is unfortunate.
From my side, feel free to close this issue.