Re: [Json] JSON "Number" interoperability issues

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 <
anders.rundgren.net@gmail.com> 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] 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/r
> fc7049] and/or 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
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

-- 

   -

   *Henry Andrews*  |  Systems Engineer
   henry@cloudflare.com
   <https://www.cloudflare.com/>

   1 888 99 FLARE  |  www.cloudflare.com
   -