wow, this looks awful and painful. There's no reason to tag the type of a field when you have a typed syntax. The real problems with JSON aren't at all addres

wow, this looks awful and painful. There's no reason to tag the type of a field when you have a typed syntax. The real problems with JSON aren't at all addressed by this: keys have to be strings lack of 'attributes' like xml, which means you have to make a document convoluted from the start. For example, lets say I am storing product data, I might do it like: {'title': "Billy goes to Buffalo", 'page_count': 193, 'author': "Ray Broadbunky"} But later I might want to be able to store attributes or metadata, in xml this doesn't change the schema of the document: <product> <title>Billy goes to Buffalo</title> <page_count>193</page_count> <author>Ray Broadbunky</author> </product> Can be extended to: <product> <title human_verified="false">Billy goes to Buffalo</title> <page_count human_verified="true">193</page_count> <author human_verified="true">Ray Broadbunky</author> </product> It's not beautiful but anything using this data will not have to change at all to add any metadata like this. However, with JSON you have to either add new data that can somehow be joined to the data originally, or more commonly you have to be very defensive and 'plan for' this stuff, greatly complicating the schema. You end up starting with: {'attributes': [ {'name':'title','value':"Billy goes to Buffalo"}, {'name':'page_count', 'value':193, ... so that you can add unanticipated things later without breaking consumers of the data but at least some are addressed: no standard way to store bytestrings lack of time type