Re: [Json] JSON "Number" interoperability issues

[Anders Rundgren <[e-mail]>]

Dear Henry,

As seen by the .NET example I'm pointing to a rather generic problem.
I don't know who "owns" it.

[e-mail] may be an appropriate venue for discussing how this could/should be addressed.

Ideally that should also involve people designing declarative schemes based on "decorating" data objects like in .NET.

For the monetary (decimal) data type there are already some standards out there that on their own seem have come to the same conclusion including the W3C: https://www.w3.org/TR/payment-request/#paymentcurrencyamount-dictionary

Thanx,
Anders

On 2018-04-21 18:14, Henry Andrews wrote:
> The JSON Schema project says no such thing.  JSON Schema says that if you want to define a sort of number that is *allowed by the JSON specification* but not interoperable by whatever definition of "interoperable" for whatever reason, then that is an ambiguity inherited from JSON and we will not exclude it from JSON Schema.
> 
> We do, however, provide many tools for constraining JSON numbers or numbers-as-strings within an interoperable subset.  I have been asking (including in conversations on issues you filed) for someone to contribute PRs on numeric / numbers-as-strings formats, but neither you nor anoyone else has stepped up.  Here is an example where I last asked for contributions in September 2017: https://github.com/json-schema-org/json-schema-spec/issues/361
> 
> I am aware that you are unhappy with our response to your issue, but please do not blame JSON Schema for JSON's ambiguities, or for other people happening to use ambiguous values while they also happen to use JSON Schema.  We help people describe how they want to use JSON.  We don't force them to use it in a particular way.  If want to avoid such values, it is entirely possible to write a JSON Schema to filter them out, and would be more possible if anyone understanding the concerns here were willing to submit a PR to define better values for "format".
> 
> thanks,
> -henry
> 
> 
> 
> 
> On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     One might believe that JSON is a done deal but if you scratch a bit on the surface it seems that this is not the case.
> 
>     The root of the problem is that JSON offers a very limited set of data types, poorly matching applications.
>     The most problematic data type is the Number type which currently is {ab}used in various ways.
> 
>     The Open API/JSON Scheme folks claim that Number should be used for everything that smells like a number including BigInteger, while Microsoft in their .NET implementation serializes a BigInteger as: "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}.  Other implementations use everything from Base64-encoding to simply putting such numbers within quotes.
> 
>     The same issue is valid for the monetary (decimal) data type which in payment-related standards like Open Banking in the UK and the W3C PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON Schema as a JSON Number.
> 
>     That is, for anything beyond what you can do natively in JavaScript, JSON offers close to ZERO interoperability.
> 
>     I-JSON [https://tools.ietf.org/html/rfc7493 <https://tools.ietf.org/html/rfc7493>] was a good start but it seems that there is more to do or is the general feeling that it is better to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/rfc7049 <https://tools.ietf.org/html/rfc7049>] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/ <https://developers.google.com/protocol-buffers/>] ?
> 
>     Personally, I don't see any fundamental issue using JSON since you can map any data type to the String type.  This is way more flexible than defining hordes of discrete data types (aka "Fixing JSON"). Mapping can be performed programmatically like obj.getBigInteger("myBigInteger") or through declarative schemes. However, without defined mapping schemes you don't get that far.
> 
>     WDYT?
> 
>     //anders
> 
> 
>     _______________________________________________
>     json mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
> 
> 
> 
> 
> -- 
> 
>   *
>     |
> 
>     *Henry Andrews*  |  Systems Engineer
>     [e-mail] <mailto:[e-mail]>
> 
>     <https://www.cloudflare.com/>
> 
>     1 888 99 FLARE  | www.cloudflare.com <https://www.cloudflare.com/>
> 
>     |
> *
>