3 ms·
In some sense JSON is unimprovable, because some properties of JSON are reached their limits. The idea of JSON is to offer two important ways to aggregate, whi
by avmich 6y ago
In some sense JSON is unimprovable, because some properties of JSON are reached their limits.
The idea of JSON is to offer two important ways to aggregate, which are different enough that they deserve separate treatment - ordered array and associative array. They are economically represented, with [] and {}, and internal structure is also made with small costs - commas (,) between elements and colons (:) for keys in associative array. We can argue that both of those features are required.
Chosen primitives - numbers, strings, booleans and null - are also selected from what's regularly and consistently used, and the choice is supported by two decades of JSON application. Roots of this selection are in design of JavaScript, which in turn relied on common practice for basic primitives.
If JSON is considered as what I think it is, structure out of basic primitives, it's at the optimal point. Crockford's decision to avoid JSON versioning makes a good sense.
Applications of JSON - human-readable texts, performance-optimized communications - can suffer from e.g. lack of built-in comments, non-extensible "type system", non-optimal bandwidth usage (if direct ASCII or even UTF-8 is used for JSON encoding, not some other compressed approach). They however can be fixed by building on top of JSON. For example, parties can agree upon reserved keys and compression schemas, constraints in form of grammars (JSON-Schema). This flexibility stems from the fact that JSON is at the very foundation of data structures, so "better than JSON" is to an extent like "better than two's complement number representation".
- earthboundkid 6y agoI think https://github.com/rentzsch/lich https://github.com/rentzsch/lich gets the basic primitives right as well, and in a binary-friendly format, but it has never been pushed by any organization, so it’s essentially unknown.
- deleted 6y ago[deleted]
- cbsmith 6y agoAgain, I think this is based on some starting assumptions about what is an ideal state, and a lot of people would argue they are flawed assumptions. It's easy to get trapped into a context when considering what the ideal solution would look like. People forget this, but ASCII (and therefore UTF-8) already has characters in it for field/record/etc. separation. One increases complexity significantly (and introduces inefficiency) by overloading other characters with their semantics. There are much more simple & efficient ways to demarcate ordered arrays in particular (e.g. simple length prefixed structures). Nulls are highly problematic for any number of reasons that are widely documented, and JSON unfortunately compounds this by having two ways of representing them (explicitly and by omission). One might quibble with the notion that a format that didn't even exist in 2000 doesn't really have two decades worth of applications working on it, but setting that aside, the design constraints of JavaScript and the challenges that have emerged from it are far from ideal. The work arounds that have emerged (the whole Number fiasco, the "standardizing" on UTF-8 while using UTF-16 when escaping, line terminators, the backslash escapign of control characters, the inconsistencies between JSON & JSONP, the binary64 "good interoperability" rule, and comments being disallowed, and of course the various JSON Schema efforts). While I agree that an ideal serialization standard would not have versioning, and Crockford's decision to avoid JSON versioning might consequently seem to make good sense... in practice this has lead to significant inconsistencies between implementations, many of which lead to interoperability problems that could at least be somewhat mitigated by versioning. (http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php) "Fixing" a bad abstraction by layering on a bad abstraction is a common house of cards meme. It is highly problematic to say the least. It's how "simple" JSON rapidly evolves to be at least as complex (and at least as error prone) as ASN.1.