The first few sections of this post nearly lost me, waffling on about NoSQL vs whatever.<p>Eventually we get to the meat:<p>> <i>For example, the JSON value</i><p><pre><code> {"s":"foo","a":[1,"bar"]}
</code></pre>
> <i>would traditionally be called “schema-less” and in fact is said have the vague type “object” in the world of JavaScript or “dict” in the world of Python. However, the super-structured interpretation of this value’s type is instead:</i><p>> <i>type record with field s of type string and field a of type array of type union of types integer and string</i><p>> <i>We call the former style of typing a “shallow” type system and the latter style of typing a “deep” type system. The hierarchy of a shallow-typed value must be traversed to determine its structure whereas the structure of a deeply-typed value is determined directly from its type.</i><p>This is a bit confusing, since JSON data commonly has an implicit schema, or "deep type system" as this post calls it, and if you consume data in any statically-typed language you will materialise the implicit "deep" types in your host language.<p>So it seems that ZSON is sort of like a TypeScript-ified version of JSON, where the implicit types are made explicit.<p>It seems the point is not to have an external schema that documents must comply to, so I guess at the end of the day has similar aim to other "self-describing" message formats like <a href="https://amzn.github.io/ion-docs/" rel="nofollow">https://amzn.github.io/ion-docs/</a> ? i.e. each message has its own schema<p>So the interesting part is perhaps the new data tools to work with large collections of self-describing messages?