Internet Object, from my limited read-through, seems to be order sensitive in a way that JSON is not. If you define a schema at the top with the available properties in some order then the values must follow that same order.

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.