Re: [Json] Adding integers to JSON (Re: JSON Schema Language)

[Phillip Hallam-Baker <[e-mail]>]

On Wed, May 8, 2019 at 1:00 PM Carsten Bormann <[e-mail]> wrote:

> On May 8, 2019, at 18:07, Nico Williams <[e-mail]> wrote:
> >
> > That's an interop bug.  They should fix it.
>
> It also nicely demonstrates the law of inevitable extensibility.
>
> JSON was designed not to provide extensibility.  Ever.
> Radical, but a well motivated idea at the time.
>

My understanding is that you can extend JSON if you like. Just call it
something else. And that makes perfect sense for a data encoding.

My extensions to JSON are called JSON-B, J-SON-C and JSON-D. Each extension
adds functionality that is critical for certain applications (verbatim
encoding of binary and text blobs, compression, data types).

Since they are strict supersets, an implementation needs separate encoders
for each one but a JSON-B decoder will serve JSON and JSON-B extensions. So
an implementation only needs one decoder.

If we were going to do a text encoding for scientific data, the changes I
would propose would be

* Hex encoding for floats so as to preserve precision of Real64 and Real32
data.
* Allow compact encoding of table data without having to specify tags for
every data item.
* Allow for comments
* Ensure that the new format can be loss-lessly converted to and from JSON.

But it would not be JSON. It would be something else. And that is OK
because if I am trying to read a data file, I need to know the encoding.

I would really like to see a JSON-like format emerge as an alternative to
CSV because, I have spent too much time trying to analyze files that
contain data separated from the context. If I am doing science, I want
files that look like this

{ "TemperatureData" : {
   "StartDate" : "2010-1-1",
   "EndDate" : "2011-2-2",
   "Location" : "Rome",
   "Units" : "Centigrade",
   "Channels" : [ "C1", "C2", "C3", "C4",
   "Readings" : [[ 20.2, 23.3, 44.3, 20.1 ... ] [34.3, 3.4 ...] ... ]

Not this
20.2, 23.3, 44.3, 20.1 ...
34.3, 3.4...
...