Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it.<p>Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization.<p>Unfortunately from what I can tell, I-JSON doesn't appear to solve this problem (or does it??) One nice thing about BSON is they made Date types first class citizens of the format.
See also RFC 7049
"Concise Binary Object Representation" (CBOR), a 'binary JSON'
<a href="http://tools.ietf.org/html/rfc7049" rel="nofollow">http://tools.ietf.org/html/rfc7049</a>
<a href="http://cbor.io/" rel="nofollow">http://cbor.io/</a><p>Faster, smaller, pretty sure it will parse on the other end.
It's great to see this! We've been bitten by JSON allowing arbitrarily large numbers at Snowplow. This is what a JSON Schema trying to enforce sensible (int64) numeric limits ends up looking like: <a href="https://github.com/snowplow/iglu-central/blob/master/schemas/org.w3/PerformanceTiming/jsonschema/1-0-0" rel="nofollow">https://github.com/snowplow/iglu-central/blob/master/schemas...</a>
I'm surprised to see nothing about formatting dates, which in my experience is the worst interop issue with JSON. I'm glad people are working on this though---thank you!
If the author of this RFC is still doing edits, I think it might be worth mentioning in section 4.2 "Must-Ignore Policy" something along the lines of,<p><pre><code> An I-JSON implementation supporting a "Must-Ignore" policy SHOULD pass any such new protocol elements on, untouched, to any downstream consumers of the message, because those downstream consumers may understand the new elements.
</code></pre>
It is another one of those things that are obvious to many people, but I could imagine somebody reading the last sentence of the section, "members whose names are unrecognized MUST be ignored", and thinking that they should omit the unrecognized elements before passing the message on.
For a lot of the tips (don't repeat keys, use ISO8601 dates), most JSON libraries should follow these conventions. So as long as you aren't hand-generating your JSON, you'd need to do very little work to conform to these guidelines.
I'd love to see someone fork <a href="https://github.com/arc90/jsonlintdotcom" rel="nofollow">https://github.com/arc90/jsonlintdotcom</a> and add an option for I-JSON validation.<p>[edit] Actually, it looks like the guts of this tool live here: <a href="https://github.com/zaach/jsonlint" rel="nofollow">https://github.com/zaach/jsonlint</a>
Kind of a bummer that nothing was suggested wrt tightening the number grammar. "99" and "99e0" are both valid serializations of 99, and "0e7" and "0" of zero. JSON also allows arbitrary trailing and leading 0s in the fraction and exponent, respectively. Personally I don't know why for instance "0.0" can't be the only valid interpretation of a double 0 and "0" be the only valid interpretation of an integer 0. In fact, why can't all floats that are ambiguous wrt an integer interpretation have a ".0" tail?<p>Also, if you're going to stash binary data in to quoted JSON strings then why base64url encoding and not Z85[0]? It's more efficient and easier to decode.<p>Using schema-less formats generally sucks.<p>[0] <a href="http://rfc.zeromq.org/spec:32" rel="nofollow">http://rfc.zeromq.org/spec:32</a>
I've run into the date formatting issue that others are mentioning, and just this weekend I discovered the hard way that the V8 JSON parser does not correctly parse the following hierarchy:<p>object --> array --> object --> array<p>I must have spent a few hours trying to figure out why Angular wasn't iterating through the first array, only to discover that it was being parsed like so:<p>object --> object --> object --> object