Re: [Json] JSON Schema Language

[Anders Rundgren <[e-mail]>]

On 2019-05-05 19:05, John Cowan wrote:
> The Scheme language makes very clear distinctions here.  Integers are a subset of rational numbers, which are a subset of real numbers, which are a subset of complex numbers, and there are predicates for detecting any of them (normally `complex?` is the same as `number?`, but if you want to add quaternions you can).
> 
> Orthogonal to this, there are exact and inexact numbers: a numeric literal can be explicitly marked as either one, but the default is that a number with a decimal point or exponent is inexact, and without either it is exact.  Mixed exactness operations produce inexact results unless the implementation can prove that the inexactness can't matter: the product of 5.0 (inexact) and 0 (exact) can be either exact or inexact.
>

That's the theory.  In practice, using the most widely deployed JSON parser there is (ECMAScript's JSON.parse()), an exact JSON Number like 555555555555555555555555555555 is truncated to 5.555555555555555e+29.  To cope with this, lots of JSON users (as well as IETF standards like RFC7515) have since years back rather turned to a JSON subset sometimes referred to as I-JSON (RFC 7493).

Using I-JSON, numbers that cannot be reliably represented by IEEE-754 double precision are serialized as JSON Strings [1]. This permits hassle-free, cross-platform JSON messaging.

https://tools.ietf.org/html/draft-handrews-json-schema-01 and "its partner in crime" the Open API does not take this in consideration.

Thanx,
Anders

1] There's actually quite a bunch of established String-serialized formats for BigIntegers out there including Decimal, Base64, Base64Url, and Hexadecimal.