On Wed, May 27, 2015 at 02:24:48PM -0600, Joe Hildebrand wrote:
However, I don't see any likely possibility that we could talk
existing JSON implementations (such as those in browsers) into
implementing these formats natively, so we're looking at completely
new code for both parsing and generation. At that point, retaining
any kind of compatibility with JSON doesn't provide a win, and
retains all of JSONs interoperability issues.
I agree that a binary JSON parser/encoder would not share much code with
a plain JSON parser/encoder, but just to be clear, having the same data
model is a win because many tools (e.g., JSON query/pointer-type tools,
such as jq) would remain usable with binary JSON.
For example, for jq to speak a binary JSON wouldn't be too hard, but for
jq to speak CBOR would require mapping CBOR non-JSON data types onto
JSON data types -- such mappings must be lossy. Alternatively jq would
need to be extended to support CBOR data types, which would require
significantly more work. (If and when we add CBOR support we'll have to
deal with this; we might never get there.)
The jq programming language is so useful to me when dealing with JSON
that I suspect it will be useful when dealing with JSON variants, but
the less they stray from the JSON data model, the easier it will be to
add support for them. I suspect this is true for many other JSON tools.
Nico
--