This format does a lot of things correctly conceptually, in my opinion. 1. It supports data tables with named and typed columns. 2. It supports types in the h

This format does a lot of things correctly conceptually, in my opinion. 1. It supports data tables with named and typed columns. 2. It supports types in the header that can be referenced elsewhere. 3. It supports lists of stuff as well as types and nesting. 4. It uses a format header to easily declare what format to decode/encode. Unlike lists of JSON objects, the data can be represented more compactly. I've done something similar when I encode tables as an array of header names, then each row is also an array, where index is used to match the name. It would be fairly easy to make a binary version of this if you needed more compact representation, and make a lossless conversion between text and binary. Why would you want a format like this? Many use cases. Every DB wire protocol essentially re-creates something like this, but often poorly. Writing multiple tables that include headers and types as well as data to disk is frequently useful. The problem with xml schema is XML is really really complex when you add in transforms and namespaces and everything else that XML can include. The only thing I might suggest is to be able to add meta-data about a specific type, or create specialized type based on type+meta-data (like max length, etc). This could also help with the issue of timestamps (local, second resolution, offset).