Internet Object – A JSON alternative data serialization format

For me a JSON alternative should at the very least offer some spec for adding comments anywhere.

Since strings don't need to be quoted, what happens during deserialization if you want the string "T"? Does this lead to the equivalent of the Norway-Problem of YAML [0]?

Is the space between the key and the type necessary? If not, how to distinguish between objects and types?

Does the validation offer some form of unions or mutual exclusion?

[0]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

One of the variants that permit comments: https://github.com/tailscale/hujson

I've been looking at data serialisation formats recently.

- JSON - TOML - CSON - INI - ENO - XML

I like CSV for tabular data obviously. This looks, as others have mentioned, like CSV with better metadata.

I like INI for its simplicity. JSON is good for more complicated data, but I have to say I like CSON.

Json is a good format to represent results of aggregation queries (group by in sql) using nesting and storing data in a single file.

Without that you would need to either

  1. store multiple not-nested (tabular, eg. csv) files and join them at the time of use.
  2. denormalize all these csvs into a single big csv duplicating the same values over and over. Compression should handle this at storage time, bht you still pay the cost when reading.
  3. store values by columns, not by rows, adding various RLE and dict encodings to compress repeated values in columns, making the files not human friendly
  4. once you store it in columns and make it unreadable, just store it as binary instead of text. You get parquet

Json and csb are simple and for that reason they won and will stay with us no matter how hard you try to add features to it.

That said I think adding a trailing comma and comments to json wouldn't be a big stretch.

The battle will be for the best columnar binary format. Parquet is the closest to a standard, but it seems to be used only as a standard for a storage. Big data systems still uncompress it and work with their own representation. The holy grail is when you get a columnar format which is good enough that big data systems use it as their underlying data representation instead of coming up with their own. I suspect such format will come from something like open sourced Snowflake, Clickhouse, Chaossearch or something like that, which has battle tested performant algorithms on them, instead of designed by committee, such as parquet.