Compact binary data option

[DonaldTsang]

Having a binary data representation of JSON5, since others have a better way of making things compact.

• http://ubjson.org/
• https://msgpack.org/
• http://bsonspec.org/
• http://bjson.org/
• http://cbor.io/
• http://rapidjson.org/

[jordanbtucker]

Most JSON5 documents can just be converted to JSON before being converted to a binary format. The only exceptions are documents that include NaN or Infinity. (This is the main reason I wrote json5/json5-spec#2.)

JSON5 isn't really meant to be a machine-to-machine language like how JSON is often used. At its heart, JSON5 is JSON for Humans. That's why configuration files make the best candidates for JSON5 documents.

If you convert JSON5 to any other representation—whether it's JSON, a binary format, a native data structure in C++, etc—you usually lose the features that make JSON5 what it is (i.e. comments are stripped, hex numbers are converted to floating points, strings are normalized, etc.).

So, supporting a binary version of JSON5 doesn't seem to provide any more benefit than just converting JSON5 to JSON and then converting that to BSON or MsgPack.

[DonaldTsang]

I was expecting a binary format specification of JSON5 to not have "lost features" as there are always ways of linting that allow JSON5 to save space.

[jordanbtucker]

@DonaldTsang I understand what you're proposing, however I'm still not convinced in the usefulness of the feature. What would you gain by having yet another binary data format?

[DonaldTsang]

I would admit that it is not entirely useful to have a binary-JSON5, from what I observe there are not many people forking JSON5 and having pull request, and that could be the reason why it hasn't really taken off yet as a ubiquitous standard.

[jordanbtucker]

I'm not sure what the ubiquity of JSON5 has to do with the need for a binary representation of JSON5, but I'm closing this for now. Thanks for the suggestion.