KerML 1.1b1 RTF Avatar
  1. OMG Issue

KERML11 — JSON serialization may lose precision or range for unbounded LiteralInteger/LiteralRational values

  • Key: KERML11-211
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

    KerML 10.4.2 (Table 14) maps the UML primitive types Integer and Real to the JSON Schema types integer and number, respectively. The normative KerML.json and SysML.json artifacts consequently declare:

    LiteralInteger.value:  {"oneOf": [{"type": "integer"}, {"type": "null"}]}
    LiteralRational.value: {"oneOf": [{"type": "number"},  {"type": "null"}]}
    

    These are the only model properties in either schema whose JSON Schema type is integer or number.

    The values of these properties are unbounded:

    • LiteralInteger::value represents a mathematical integer (8.3.4.8.12; 9.3.2.2.3).
    • LiteralRational::value represents a rational value (8.3.4.8.13; 8.4.4.9.2, Note).
    • The textual notation places no bound on the number of digits in DECIMAL_VALUE or EXPONENTIAL_VALUE (8.2.2.4, 8.2.5.8.4).

    JSON syntax itself does not impose a fixed numeric range or precision. However, RFC 8259 section 6 explicitly permits implementations to limit the range and precision of accepted numbers and states that good interoperability is achieved when no more range or precision than IEEE 754 binary64 is expected. It further identifies integers in the range [-(2^53)+1, (2^53)-1] as interoperable in the sense that implementations using binary64 will agree exactly on their numeric values.

    RFC 7493 (I-JSON) section 2.2 similarly states that numbers requiring greater magnitude or precision than IEEE 754 binary64 should not be sent when interoperability is required, and recommends representing such values as strings.

    Consequently, the current KerML JSON mapping does not provide an implementation-independent lossless representation for all legal LiteralInteger and LiteralRational values. An implementation using arbitrary-precision numeric representations can preserve such values, but another conforming JSON implementation is permitted to process them with more limited range or precision.

    For example, with IEEE 754 binary64 numeric processing:

    • 9007199254740993 cannot be represented exactly and is rounded to 9007199254740992.
    • 9223372036854775807 and 9223372036854775808 are distinct integers, but both are converted to the same binary64 value, 2^63. A decimal reserialization of that binary64 value therefore cannot preserve both original values.
    • 1.234567890123456789012345678901 cannot be represented exactly and is rounded to approximately 1.2345678901234567.
    • 1E400 exceeds the finite range of binary64 and therefore cannot be represented as a finite binary64 value at all.

    All of these values are legal in the KerML textual notation and denote valid Integer or Rational values, but their exact values cannot be preserved by such processing.

    This creates an interoperability gap in the JSON serialization: a producer cannot use an alternative lossless representation, such as a decimal string, while remaining conformant to the current KerML.json and SysML.json schemas, because the relevant properties permit only JSON numbers or null.

    As a result, the current JSON serialization does not provide a portable, lossless representation for the full value domains permitted by KerML numeric literals.

  • Reported: KerML 1.0b2 — Wed, 30 Sep 2026 07:24 GMT
  • Updated: Wed, 30 Sep 2026 07:31 GMT