Last week I sug­gest­ed some mod­est JSON im­prove­ments, and con­ver­sa­tion en­sued. Ob­vi­ous­ly, much was “He’s Wrong On The In­ter­net (again)” but lots was juicy and tasty, and worth con­sid­er­ing fur­ther.

This is based on re­ac­tion in my own com­ments, and on Hack­er News.

“Just use X” · For val­ues of X in­clud­ing Hj­son, Ama­zon Ion, edn, Tran­sit, YAML, and TOML.

Nah, most of them are way, way rich­er than JSON, of­ten with fully-worked-out type sys­tems and Con­cep­tu­al Tu­to­ri­als and so on. I just want JSON that’s eas­i­er to ed­it and can do times­tamp­s.

Hm­m, SON looks pret­ty close to what I’m think­ing.

Al­so, I gath­er that edn sim­ply as­serts that com­mas are whites­pace, which smells sort of bril­liant to me.

“Comments, please please comments!” · Can’t think of a good rea­son to say no. # or // and/or /* */? Why use two char­ac­ters where one would do? I’m think­ing #.

“You shouldn’t want to hand-edit JSON” · Yeah, I shouldn’t and ac­tu­al­ly I don’t. But some­how I keep hav­ing to. And it’s a suck­y, hor­ri­ble, ex­pe­ri­ence, but it doesn’t have to be.

“You’ll lose JavaScript compatibility!” · Sor­ry, JSON al­ready isn’t a JavaScript sub­set. Al­so, you should nev­er use eval() on JavaScrip­t, the right ap­proach is al­ways JSON.­parse() and JSON.­toString() or your language’s equiv­a­len­t.

“Unquoted field names, please!” · Bah, can’t see the ben­e­fit. If I have to look at the val­ue to de­cide whether to quote it, I’m do­ing it wrong.

Is it too late? · The on­ly re­al ar­gu­ment is whether it’s coun­ter­pro­duc­tive, or maybe just too late, to try to prune some JSON ir­ri­tants. Can’t say as I know. Any­how, if it were worth do­ing, I think you could build a con­sen­sus around:

  1. Declar­ing that com­mas are whites­pace,

  2. adding com­ments (I’d vote for # but what­ev­er), and

  3. adding RFC3339 times­tamps  —  people seemed to like the @-prefix idea too.

One nice con­se­quence is that all ex­ist­ing JSON would al­so be the .next ver­sion or what­ev­er we call it. Speak­ing of which, I even picked a catchy name and snagged the do­main. So far, not hear­ing the drum­beat of vir­tu­al feet on the vir­tu­al street though.



Contributions

Comment feed for ongoing:Comments feed

From: Grahame Grieve (Project Lead, FHIR) (Aug 25 2016, at 21:37)

Yes please. Like those changes. Lots+++

[link]

From: Don MacAskill (Aug 26 2016, at 00:20)

Please, for the love of God, talk about some sort of binary compatibility or standard encoding of binary or something. :)

[link]

From: Daniel Ly (Aug 26 2016, at 00:21)

Sorry to nitpick but I wonder if you meant RFC 3339?

https://tools.ietf.org/html/rfc3339

[link]

From: Matthew (Aug 26 2016, at 01:15)

Perhaps it could become as popular as XML 1.1.

[link]

From: Luci (Aug 26 2016, at 01:46)

Commas being whitespace is taken directly from Clojure, where it does indeed work very well. Most code never uses them, except for cases where it would help readability (just like whitespace).

I have similar gripes with JSON as yourself and none of the suggested alternatives seem good enough.

I really would like a reasonable schema system and ideally also a binary serialisation based on given schemas.

[link]

From: Vinny Fonseca (Aug 26 2016, at 04:05)

Hi Tim,

Good ideas and a good start for this conversation. I deal with JSON day in day out and it really needs some fixes.

In my opinion:

- the key should always be unquoted and allow single words only in a key/value pair

- the comment syntax should be // and /* */ for block comments, instead of #, as JSON is still closely associated with JS

Other than that, I agree with JSON.parse and JSON.toString usage at the application level, the timestamps implementation and commas as whitespace.

[link]

From: Carlos Fernández (Aug 26 2016, at 05:04)

Those ones are good approaches, but shouldn't be 'fixes'.

The problem here is that people have been using JSON the way they shouldn't, and the way JSON should be used doesn't need spaces instead of commas, comments and so. (The @date approach would be nice, maybe, not sure).

If you want something that looks somehow like JSON but have different syntax and objective, don't call it JSON\JSON.next, just use another name, because it's a different thing.

[link]

From: StanD. (Aug 26 2016, at 11:38)

I still think edn is the solution. In addition to treating commas as whitespace it also

* Dispenses with the colon between keys and values (it's not whitespace though)

* Has single character comments (the semi-colon)

* Has keywords (:key, for example) which can be used as keys. Easier to type than double-quotes.

* Supports dates via reader literals (#inst "2012-03-22T10:20:00Z" is a date)

The reader literal system is extensible if you want (#UUID "[uuid string]" is also built in, for example) but parsers can just treat them as strings as a fallback.

[link]

From: Bob Foster (Aug 26 2016, at 17:43)

# for comments? You want to make whitespace significant? Good grief.

[link]

From: Jesse Wilson (Aug 27 2016, at 05:55)

I’d love it if a revised JSON spec made a general recommendation on the case format of names. It’s sad when an integration breaks because the client sent `full_name` when the server expected `fullName`. Even a weak endorsement of a specific scheme could help to reduce the number of dialects we need to use.

[link]

author · Dad · software · colophon · rights
picture of the day
August 22, 2016
· Technology (79 fragments)
· · Internet (105 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.