I’m confused. What’s the point of this RFC? Isn’t it just referencing the JSON RFC in almost every section? What makes I-JSON different than regular JSON, apart from the recommendation of storing timestamps in ISO 8601 format?
Also important is the requirement that order of keys in objects be ignored. I’ve had to use a few JSON APIs where order is significant, and they’re a royal pain to deal with in languages/libraries that convert JSON objects to hash-table-based collections, such as NSJSONSerialization in Objective-C and Swift.
It disallows repeated keys in objects, which is otherwise allowed in both the JSON RFC and ECMA-404.
Some other subsets require the values of key: value pairs to have the same “type/shape”. I note I-JSON provides no such restriction.
Why are you confused, it’s explained clearly in section 1 and 2.
e.g., all strings are invalid UTF-8 right, when sending numbers, one shouldn’t expect very high precision and encode them as string if necessary
This is from 2015 so I guess there wasn’t a lot of uptake?
Loads of stuff was using a restricted subset of JSON similar to this from the very beginning. I’d bet most JSON APIs use exclusively UTF-8, no invalid unicode, no duplicate keys, make sure to use strings for numbers which may not be representable in 64-bit floats, send binary data as base64-encoded strings, follow the must-ignore policy, etc. It’s just nice to have this stuff standardized, so that people can validate that their JSON parsers accept everything in I-JSON and protocol designers can ensure that they only output I-JSON.
I’d bet that if we analyzed all JSON web traffic, we’d find that a huge amount of it follows I-JSON (though probably mostly unintentionally).
given that all valid i-json is valid json, you’ll might never know :-)
The “I” is for “lowest common denominator “.
Amazon Ion is very well thought out, and very related. https://amzn.github.io/ion-docs/
I agree, but it’s a superset of JSON, where I-JSON is a subset. Different use cases, I think.