Subject: [Json] JSON irritants

From: Tim Bray <[email-masked]>
Date: Tue, 2 Aug 2016 22:17:36 -0700

I have recently been doing an unreasonable amount of JSON work, what with
editing the drafts here, helping design AWS’s CloudWatch Events service
[1], and now working on an interesting JSON DSL that with any luck will
decloak later this year.

I have encountered the following irritants:

1. When hand-editing JSON, it is unreasonably difficult to get the commas
right.
2. When using JSON numbers, the sender *always* knows whether integers or
floats are intended, but there’s no way to communicate this information.
3. There is no timestamp literal.

Then I realized that the comma is not necessary to the grammar, it’s only
there for JavaScript compatibility.  Bah.  Anyhow, here’s the example
object from RFC7159:

   {
     "Image": {
         "Width":  800,
         "Height": 600,
         "Title":  "View from 15th Floor",
         "Thumbnail": {
             "Url":    "http://www.example.com/image/481989943",
             "Height": 125,
             "Width":  100
         },
         "Animated" : false,
         "IDs": [116, 943, 234, 38793]
       }
   }

Here’s a version with a couple more fields and the irritants removed:

  {
     "Image": {
         "Width":  i800
         "Height": i600
         "Title":  "View from 15th Floor"
         "Thumbnail": {
             "Url":    "http://www.example.com/image/481989943"
             "Height": i125
             "Width":  i100
         }
         "Location": {
             "Latitude": f49.399673
             "Longitude": f-123.508437
         }
         "Animated" : false
         "Capture Time": @2016-08-01T18:15:00Z
         "IDs": [i116 i943 i234 i38793]
       }
   }

I thought of a friendly acronym and bought a domain name and wrote an I-D
too, but I thought it might be polite and useful to test the waters here,
example first.

[1]
http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatchEventsandEventPatterns.html

---

From: Christian Zangl <[email-masked]>
Date: Wed, 3 Aug 2016 07:45:51 +0200

For hand-editing JSON you may want to take a look at Hjson 
(http://hjson.org).

On 2016-08-03 07:17, Tim Bray wrote:
> I have recently been doing an unreasonable amount of JSON work, what
> with editing the drafts here, helping design AWS’s CloudWatch Events
> service [1], and now working on an interesting JSON DSL that with any
> luck will decloak later this year.
>
> 1. When hand-editing JSON, it is unreasonably difficult to get the
> commas right.
> 2. When using JSON numbers, the sender *always* knows whether integers
> or floats are intended, but there’s no way to communicate this information.
> Then I realized that the comma is not necessary to the grammar, it’s
> only there for JavaScript compatibility.  Bah.  Anyhow, here’s the
> example object from RFC7159:
>
>    {
>      "Image": {
>          "Width":  800,
>          "Height": 600,
> I thought of a friendly acronym and bought a domain name and wrote an
> I-D too, but I thought it might be polite and useful to test the waters
> here, example first.
>
> [1] http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatchEventsandEventPatterns.html
>
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Manger, James" <[email-masked]>
Date: Wed, 3 Aug 2016 16:15:54 +1000

Yuck for i800 and f49.399. I’d prefer the presence of a decimal point “.” or exponent symbol “e” to imply a float; and their absence to imply an integer.

Optional commas sounds okay. I wouldn’t like to forbid them as [11, 234, 5, 6] is nicer than [11 234 5 6].

Encouraging yyyy-mm-ddThh:mm:ss[.sss…]Z for instants of time is great. I’m less sure that distinguishing it from a string is so crucial.

--
James Manger

From: json [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Wednesday, 3 August 2016 3:18 PM
To: [email-masked]
Subject: [Json] JSON irritants

I have recently been doing an unreasonable amount of JSON work, what with editing the drafts here, helping design AWS’s CloudWatch Events service [1], and now working on an interesting JSON DSL that with any luck will decloak later this year.

1. When hand-editing JSON, it is unreasonably difficult to get the commas right.
2. When using JSON numbers, the sender *always* knows whether integers or floats are intended, but there’s no way to communicate this information.
3. There is no timestamp literal.

Then I realized that the comma is not necessary to the grammar, it’s only there for JavaScript compatibility.  Bah.  Anyhow, here’s the example object from RFC7159:

   {
     "Image": {
         "Width":  800,
         "Height": 600,

  {
     "Image": {
         "Width":  i800
         "Height": i600

I thought of a friendly acronym and bought a domain name and wrote an I-D too, but I thought it might be polite and useful to test the waters here, example first.

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Aug 2016 09:39:46 -0400

Manger, James scripsit:

> Yuck for i800 and f49.399. I’d prefer the presence of a decimal
> point “.” or exponent symbol “e” to imply a float; and their
> absence to imply an integer.

+1.  That is how my JSON parser works in any case.

> Optional commas sounds okay. I wouldn’t like to forbid them as 
> [11, 234, 5, 6] is nicer than [11 234 5 6].

I think an important point is being allowed to include a redundant
final comma.

> Encouraging yyyy-mm-ddThh:mm:ss[.sss…]Z for instants of time is
> great. I’m less sure that distinguishing it from a string is so
> crucial.

Mmm, I think it's good to have it as a separate type.  I don't see any
need for the @ prefix, though.  A date-time literal doesn't look like
anything else.

But as someone who tried with XML 1.1 and XML 1.0 5e, I suspect that
any such effort as this is doomed to obscurity.  The improvements
aren't massive enough to be worth the conversion effort and loss of
interoperability.

FtanML, now ...
<http://www.balisage.net/Proceedings/vol10/print/Kay01/BalisageVol10-Kay01.html>

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
Mos Eisley spaceport.  You will never see a more wretched hive of scum
and villainy --unless you watch the Jerry Springer Show.
        --georgettesworld.com

---

From: Wendy Roome <[email-masked]>
Date: Wed, 03 Aug 2016 11:08:23 -0400

On 08/03/2016, 09:39, "John Cowan², [email-masked]> wrote:

>Manger, James scripsit:
>
>> Yuck for i800 and f49.399. I¹d prefer the presence of a decimal
>> point ³.² or exponent symbol ³e² to imply a float; and their

Ditto.

>
>> Optional commas sounds okay. I wouldn¹t like to forbid them as

An optional final comma would be very convenient. But I think optional
separator commas, with some rule to impute a comma at the end of a line,
is a bad idea. Suppose the json runs thru a compressor that automagically
squeezes out unnecessary white space. The result would be illegal unless
the compressor understood the new rules.

>
>> Encouraging yyyy-mm-ddThh:mm:ss[.sssŠ]Z for instants of time is
>> great. I¹m less sure that distinguishing it from a string is so
>> crucial.
>

I think that is getting too complex. Better to use strings and have the
end apps agree that this field is a date.

>aren't massive enough to be worth the conversion effort and loss of

*SIGH*

I have to agree with that 1000%. Much as it would be nice to extend JSON
like that, interoperability will prevent it. There are *a lot* of JSON
libraries out there. When would you, as a JSON creator, think it is safe
to assume that every JSON library your client apps will use understands
the extensions? My guess is that would be about the same time that we
start worrying about the Y10K problem. :-)

For example, think about the number of time you write <tag /> instead of
<tag/>, because some early xml parser didn't handle the latter properly.

	- Wendy Roome

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Aug 2016 11:35:28 -0400

> the compressor understood the new rules.

If it didn't understand the new rules, it wouldn't accept [1 2 3] or
{"foo":"bar" "baz":"zam"} in the first place, so I don't think that's
a separate problem.

> <tag/>, because some early xml parser didn't handle the latter properly.

Actually, it's older HTML parsers that had that problem, not XML ones.
Empty-tags didn't exist when HTML was derived from SGML.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
There is no real going back.  Though I may come to the Shire, it will
not seem the same; for I shall not be the same.  I am wounded with
knife, sting, and tooth, and a long burden.  Where shall I find rest?
                --Frodo

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 4 Aug 2016 17:49:28 +0000

>For hand-editing JSON you may want to take a look at Hjson 

+1 to this.  Please at least look at the existing work that has been done in this space before recreating it.  One upside is that there is existing code...

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 4 Aug 2016 17:50:51 +0000

>aren't massive enough to be worth the conversion effort and loss of

First: imagine a new media type.  Second: comments are a big enough win to cause at least some adoption for configuration files.

-- 
Joe Hildebrand

---

From: John Cowan <[email-masked]>
Date: Thu, 4 Aug 2016 15:24:48 -0400

> First: imagine a new media type.  Second: comments are a big enough win to cause at least some adoption for configuration files.

Sure, and that way of thinking leads to YAML, which has had some success.
But it hasn't turfed out JSON, and it's unlikely that anything else will
turf out YAML.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
They do not preach that their God will rouse them
A little before the nuts work loose.
They do not teach that His Pity allows them
to drop their job when they damn-well choose.
                --Rudyard Kipling, "The Sons of Martha"

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 4 Aug 2016 19:56:23 +0000

>But it hasn't turfed out JSON, and it's unlikely that anything else will

Agree.  Let a dozen flowers bloom.  Media types are cheap.

-- 
Joe Hildebrand

---

From: Rob Sayre <[email-masked]>
Date: Thu, 4 Aug 2016 20:00:45 -0700

There are plenty of wire formats that don't have these problems. None of
them are called "JSON", and this one shouldn't be either (doesn't sound
like it will be).

YAML, TOML, Avro, Thrift, CBOR, Protocol Buffers, and many others all
address some of these problems. Some aren't as self-describing as JSON is.

- Rob