Last week I suggested some modest JSON improvements, and conversation ensued. Obviously, much was “He’s Wrong On The Internet (again)” but lots was juicy and tasty, and worth considering further.
Nah, most of them are way, way richer than JSON, often with fully-worked-out type systems and Conceptual Tutorials and so on. I just want JSON that’s easier to edit and can do timestamps.
Hmm, SON looks pretty close to what I’m thinking.
Also, I gather that edn simply asserts that commas are whitespace, which smells sort of brilliant to me.
“Comments, please please comments!” ·
Can’t think of a good reason to say no.
/* */? Why
use two characters where one would do? I’m thinking
“You shouldn’t want to hand-edit JSON” · Yeah, I shouldn’t and actually I don’t. But somehow I keep having to. And it’s a sucky, horrible, experience, but it doesn’t have to be.
JSON.toString() or your language’s equivalent.
“Unquoted field names, please!” · Bah, can’t see the benefit. If I have to look at the value to decide whether to quote it, I’m doing it wrong.
Is it too late? · The only real argument is whether it’s counterproductive, or maybe just too late, to try to prune some JSON irritants. Can’t say as I know. Anyhow, if it were worth doing, I think you could build a consensus around:
Declaring that commas are whitespace,
adding comments (I’d vote for
# but whatever),
adding RFC3339 timestamps — people seemed
to like the
@-prefix idea too.
One nice consequence is that all existing JSON would also be the .next version or whatever we call it. Speaking of which, I even picked a catchy name and snagged the domain. So far, not hearing the drumbeat of virtual feet on the virtual street though.