ValueOnly Example Illustrating Precision Problems

[sebbader-sap]

Is your feature request related to a problem? Please describe.

ValueOnly serialisation has effects on the precision of contained values. A easily understandable example is missing, therefore significant amount of readers of the spec might not be aware of this.

Describe the solution you'd like

See the todo in https://github.com/admin-shell-io/aas-specs/blob/dbd9c91fed96e95b40acec1bef6fca66d8c9c4fd/documentation/IDTA-01001/modules/ROOT/pages/includes/IDTA-01001_ValueOnly.adoc?plain=1#L159: Add an example roundtrip, where the input is different to the output and explain why this can be a problem.

Additional context

Was considered a Todo for the was-specs-api community first but as the ValueOnly chapter has moved, I am also creating this issue here.

[sebbader-sap]

@alexgordtop assigning it to you already as you agreed in one of the api meetings to create such an example. Bad luck :-)

[alexgordtop]

PARSE_JSON: Input number: 51.4166919 cannot round-trip through string representation
this is a longitude/latitude, same as above

or

"For reference, I have two numbers that are castable to FLOAT64 but cannot parse the JSON with exact wide_number_mode because it errors out.

Parsing the JSON with the default 'exact' mode crashes.

From parsing the JSON with wide_number_mode => 'round'

50.0007544437 -> 50.000754443700004
1.3085912824 -> 1.3085912824000001
From using CAST

CAST("50.0007544437" AS FLOAT64) -> 50.0007544437
CAST("1.3085912824" AS FLOAT64) -> 1.3085912824

Source: https://issuetracker.google.com/issues/231030459?pli=1

The issue is, that a user assumes, that he uses a decimal number - where in fact a float/double number is used - with all the issues that come along with that.

In cases with required high precision (cash flow, structural integrity, ai), json numbers may introduce unexpected issues.

[BirgitBoss]

see also this information on round-trip for JSON schema: https://github.com/admin-shell-io/aas-specs/tree/master/schemas/json#hint-round-trip-conversions

[BirgitBoss]

This is written in the chapter for valueOnly:

Note 1: due to the limits in the representation of numbers in JSON, the maximum integer number that can be used without losing precision is 2⁵³-1 (defined as Number.MAX_SAFE_INTEGER). Even if the used data type would allow higher or lower values, they cannot be used if they cannot be represented in JSON. Affected data types are unbounded numeric types xs:decimal, xs:integer, xs:positiveInteger, xs:nonNegativeInteger, xs:negativeInteger, xs:nonPositiveInteger and the bounded type xs:unsignedLong. Other numeric types are not affected. footnote:[cf. https://openmanufacturingplatform.github.io/sds-documentation/bamm-specification/v1.0.0/datatypes.html (with adjustments for +/-INF, NaN, and language-typed literal support)]

and

Note 2: the ValueOnly-serialization uses JSON native data types, AAS in general uses XML Schema Built-in Datatypes for Simple Data Types and ValueDataType. In case of booleans, JSON accepts only literals true and false, whereas xs:boolean also accepts 1 and 0, respectively. In case of double, JSON number is used in ValueOnly, but JSON number does not support INF/-INF (positive Infinity/negative), which is supported by xs:double. Furthermore, NaN (Not a Number) is also not supported.

[BirgitBoss]

@alexgordtop

CAST("50.0007544437" AS FLOAT64) -> 50.0007544437 CAST("1.3085912824" AS FLOAT64) -> 1.3085912824

the values are identical... I expected we need an example

CAST("" as FLOAT64) _> CAST( as STRING) ->

and they should differ...