←back to thread

Fixing JSON

(www.tbray.org)
139 points robin_reala | 5 comments | | HN request time: 0s | source
Show context
outsidetheparty ◴[] No.12327880[source]
Shameful confession: when I was first introduced to JSON, I was convinced it would go nowhere. "XML already does everything JSON does! And there's no way to differentiate between nodes and attributes! And there are no namespaces! And no schemas! What's the point of JSON?" And a couple of years later I looked up from the tangled mess of XSLT I was working on to discover that the rest of the world had moved on.

JSON is just javascript, and it leaves out everything else. That's its entire reason for existing, and it caught on because that's all that 99.44% of anyone needed.

Timestamps you can add today, without changing the protocol; just put them in your data if you need them. So I'm not sure what he's even proposing there.

Schemas: OK, he doesn't like JSON Schema's anyOf. Fair enough. There's no real proposal here for how to fix it, so not much to say here.

Replacing commas with whitespace sounds to me like replacing a very minor irritant with a constant full-body rash. Stuff like his example of "IDs": [ 116 943 234 38793 ] would lead to far more confusion and errors than the occasional stray trailing comma.

So I guess I pretty much vote no on this one thanks for asking

replies(9): >>12327976 #>>12328071 #>>12328074 #>>12328283 #>>12329722 #>>12329776 #>>12330073 #>>12330517 #>>12334062 #
xvolter ◴[] No.12328283[source]
I was thinking along very similar lines when reading the article by Tim Bray. JSON is designed for JavaScript compatibility, I almost stopped reading when he said:

> They’re inessen­tial to the gram­mar, just there for JavaScript com­pat­i­bil­i­ty.

The entire article goes on to suggest extremely terrible solutions to the problems he is pointing out.

In order:

Commas: If comma's are an annoyance, is that to mean there is no annoyance with XML markup? You can forget a closing tag just as easily, probably more easily. Just get a JavaScript or JSON linter. Fixed. If you are really annoyed by commas, move to YAML or another format.

Datetimes: Just store your dates in a standardized timezone and format, how about [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). You can also use a [JSON-Schema](http://json-schema.org/) if you really want.

Schemas: There's lots of potentials here. However, again, if you're going to change JSON so much, why not just pick another data format that has better schema support.

replies(5): >>12329120 #>>12329744 #>>12329802 #>>12330331 #>>12334990 #
1. anon1385 ◴[] No.12329802[source]
>JSON is designed for JavaScript compatibility, I almost stopped reading when

Why does Javascript compatibility matter in 2016? The original idea for JSON might have been to parse untrusted data using js eval() but I'd hope that nobody is doing that anymore.

replies(1): >>12329829 #
2. xvolter ◴[] No.12329829[source]
I don't believe the original purpose of JSON was to eval untrusted objects, since that would always have posed a security risk. It did however offer a very easy standard way to share and parse data back in 1999. In 2016, I believe continued backwards compatibility is a necessity; otherwise you are just creating a new data storage format. So removing commas doesn't seem like an acceptable improvement, especially when the recommendation comes out of a necessity due to human error while hand-editing. JSON is incredibly easy to read and write by hand, in comparison with XML it is far easier to parse and traverse through code do its significantly simplified structure. If however, you need more functionality, switch to a different format; why bother trying to mangle or force JSON to work where it doesn't. There are other technologies and standards out there, use them.
replies(1): >>12330687 #
3. macspoofing ◴[] No.12330687[source]
>It did however offer a very easy standard way to share and parse data back in 1999.

Not 1999. 2004. JSON wasn't on anybody's radar in 1999.

>JSON is incredibly easy to read and write by hand, in comparison with XML

Maybe for small shallow objects (and for those XML is also quite readable). Once size or complexity get a little higher, you're done.

replies(1): >>12330748 #
4. hutzlibu ◴[] No.12330748{3}[source]
> Once size or complexity get a little higher, you're done.

And what is better than JSON, when it gets complex?

replies(1): >>12330844 #
5. macspoofing ◴[] No.12330844{4}[source]
I meant you're done with reading and writing it by hand.