Subject: [apps-discuss] Extended JSON encodings JSON-B, JSON-C, JSON-D

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jun 2013 21:21:32 -0400

Following on from Paul and Carsten's useful discussion on binary encodings
and comments by Nico et. al. I propose a different approach:

JSON-B 'Binary'
    Is a strict superset of JSON encoding that adds binary encodings for
Javascript data types (Integer, double, String) and a binary data type.

JSON-C 'Compact'
    A strict superset of JSON-B that adds in simple string compression byt
replacement with tag codes

JSON-D 'Data'
    Adds in additional floating point types that are useful for encoding
scientific data.

The basic idea here is to minimize the impact of adding the additional
encodings when using them in a Web Service. All valid JSON encodings are
also valid JSON-B encodings. begin-object '{' and begin-array '[' have the
same code values in each. All the new codes are in the range x80-xFF so as
to avoid conflicts.

One decoder can read both lexical forms. So I would imagine this could be
implemented in JavaScript etc. pretty easily. All you would need to know is
what the capabilities of your decoder are so that you can tell the sender
what is acceptable.

If you are debugging a Web Service, you might tell the system to send data
in plain old JSON so you can read it.

There is no canonical encoding defined. So there are 5 different encodings
for '42': byte, Int16, Int32, Int64, Bignum16

I did not define a date type. This is tempting but probably a bad idea as
there is really no agreement on what the representation of time should be.
If a choice was to be forced it should probably be to specify a time quanta
as 100 nanosecond units as per Windows since that allows a 64 bit value to
represent approx. 58,000 years and thus be Y10K compliant.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jun 2013 21:22:31 -0400

Once more with the link to the draft:

http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.txt

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Jun 2013 20:55:31 -0500

> same code values in each. All the new codes are in the range x80-xFF so as

Using byte values that don't appear in UTF-8 might help w.r.t.
auto-detection.  You might want to have a byte value that's akin to
whitespace, a value that all top-level values in your encoding can
start with, that way there's no ambiguity.

> what the capabilities of your decoder are so that you can tell the sender

This is good.

> represent approx. 58,000 years and thus be Y10K compliant.

That representation works for me (with the epoch
1601-01-01T00:00:00Z).  Signed or unsigned?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jun 2013 22:13:12 -0400

> start with, that way there's no ambiguity.

Perhaps you could propose a preamble sequence?

> 1601-01-01T00:00:00Z).  Signed or unsigned?

Following the principle of copying JavaScript types, would mean using a
signed 64 bit integer with millisecond resolution with an epoch of
1970-01-01T00:00:00Z

I think it would actually be a good idea to also support the Windows .NET
100 nanosecond resolution in JSON-D. This has a base of Jan 1 0001 in the
Gregorian calendar and is always positive:

The value of this property is the number of 100-nanosecond intervals that
have elapsed since 12:00 A.M., January 1, 0001.