JSON Alternative – Internet Object

And what happens with sparse data? In JSON you simply omit the properties (key value pairs) from the JSON object all together when there is no data for the given property. For Internet Object you presumably need to insert "null" values in the column you have no data for?

I can see how omitting the "header" names from each "object" in a vector/array of objects can save space, but there are no mentions of trade-offs. And if you gzip a JSON body then the compression algorithm will get rid of those repeated bytes in any case, at the expense of some additional CPU resources being used. Running the example data through gzip proves this:

Original sizes:

- io: 51K

- json: 88K

gzip sizes:

- io: 20K

- json: 21K

The more interesting tidbit was the embedded schema for validation of data I think. The splitting "headers" and data seems less important. I also think maybe showing some speed comparisons of serializing and deserializing internet object and json data would be nice. Though this would necessarily depend on using the same programming language and writing an optimal internet object serializer to get a fair comparison.

This comment might come off as overly negative or disparaging. Kudos to the author for coming up with a new data format to solve an observed problem.

https://en.wikipedia.org/wiki/Robustness_principle

Other than this, other document formats such as TOML haven't seen much action in spite of being arguably simpler and requiring less data than JSON.

why "int" means type, and "street" does not?

> active?:bool

it seems that this is legal:

active?: bool, someattr?: bool T

now which one was set?

This might be very useful replacement for CSV, but not JSON.

There is no concept of headers in JSON. And neither is there in the proposed Internet Object. The (ugly?) example of https://internetobject.org/the-story/ can be written in any data format (thinking of Yaml) and obviously also in the "Internet Object".

There are reasons to blame JSON for, such as the lack of comments. But the lack of schema is plain wrong -- there is JSONschema and there are validators which can be perfectly used when recieving data over the web, for instance.