IETF standard for I-JSON compliant extended numeric data types

[cyberphone]

A limited research effort validated my suspicions that platform architects have created (or are in the process of creating), their own proprietary solutions for supporting data types which doesn't naturally fit into the number universe limited by IEEE-754 double precision.

As an example the .NET DataContractJsonSerializer serializes BigInteger as "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1} which is entirely incompatible with the same solution for Java.

Related:
#845
https://github.com/javaee/jsonb-spec/issues/80#issuecomment-383465639
https://github.com/dotnet/corefx/issues/29271
json-iterator/go#267

Is there anybody out there who might be interested in co-authoring an Internet-Draft addressing this topic?

[darrelmiller]

@cyberphone I'm not aware of anyone in the .net space who would voluntarily use the DataContractJsonSerializer. The performance is way below any of the other tools available. It isn't the default serializer used by recent Microsoft tooling and as far as I know there is no more work going into it. I wouldn't recommend basing any decisions on the behaviour of that library.

[cyberphone]

Thanx @darrelmiller Json.NET seems to do a more reasonable job:

using System;
using System.Numerics; 

using Newtonsoft.Json;
using Newtonsoft.Json.Serialization;

namespace newtonsoft
{
    public class MyObject
    {
        public string id;

        public long counter;

         public BigInteger biggie;
    }

    class Program
    {
        static void Main(string[] args)
        {
            MyObject myObject = new MyObject
            {
                counter = 3,
                id = "johndoe",
                biggie = 65655565656556566L,
            };
            Console.OutputEncoding = System.Text.Encoding.Unicode;
            Console.WriteLine(JsonConvert.SerializeObject(myObject));
        }
    }
}

Output:

{"id":"johndoe","counter":3,"biggie":65655565656556566}

However, it is not I-JSON compatible which this particular issue is about. I'm just looking for a suitable "home" for such definitions.

[darrelmiller]

JSON.NET has an extensibility mechanism to change how types are serialized, so if you wanted to follow the I-JSON recommendation for serializing big integers you could do that. Personally, I try to avoid automatic type serializers, so it's not a problem I've run into before.

Petitioning the various JSON parsing libraries to implement a "I-JSON" mode seems like most promising approach to reach your goal. Although, I suspect it is going to be an uphill battle. I don't often hear people talking about I-JSON.

[akuckartz]

I don't often hear people talking about I-JSON.

As far as I remember whenever I mentioned that specification it was considered and adopted.

[cyberphone]

I don't often hear people talking about I-JSON.

Agreed. There are though important standards out there (like JOSE) that without mentioning it effectively are based on/compliant with I-JSON beacuse they target browsers and Node.js as well.

There's not an awful lot of JSON-based software that uses a "money" type. However, the only public schemes I'm aware of indeed use an I-JSON compliant serialization.

It is possible that only Oracle/Java will support a true I-JSON option since (as you say), annotations can do the same job. How OpenAPI eventually will deal with the list of proposed new data types should also have an impact on the success or failure of this quest 😂

[cyberphone]

It turned out that the Oracle/Java JSON API actually is I-JSON compatible by default through a method which I have coined Adaptive Notation:

{
  "BigDecimal.large": "1E+999",
  "BigDecimal.small": 1,
  "BigInteger.large": "240777489003222785532321",
  "BigInteger.small": 1,
  "Long.large": "9223372036854775807",
  "Long.small": 1
}

@darrelmiller How would this fit into OpenAPI? I mean, could this evolve into a JSON standard?

Personally I prefer schemes where you either use JSON Number or JSON String, rather than mixing these depending on the actual value. However, the most important is finding a common solution.

https://github.com/cyberphone/I-JSON-Number-System#extended-numeric-data-types-compliant-with-i-json

[cyberphone]

This topic has now reached an unprecedented level of weirdness:
tc39/proposal-bigint#24 (comment)

[handrews]

I don't see any specific action for us to take here (it's not a repo for discussing new IETF I-D ideas, nor is it a repo for .NET implementations of JSON), and the OP has stated that he's moved on to CBOR in a separate issue, so I'm closing this.