Disagree. JSON can be deserialzed to hashmaps / lists with a single call that has no schema or parsing instructions. The spec unambiguously deserializes a "dat

Disagree. JSON can be deserialzed to hashmaps / lists with a single call that has no schema or parsing instructions. The spec unambiguously deserializes a "data document" to a data structure. XML cannot do this: - possibility of text being just ... somewhere ... it wasn't intended. - tag data vs attribute data: ambiguous - a list CAN be represented in XML, but there is no array begin/end indicator like JSON that will confirm that the tags are a list, versus some other screwy thing - finally, JSON can represent a "data document" that is just an array/list, while XML cannot do this unambiguously. It has to have a root tag. As for schema validation, that was always a hack. Schema will ultimately encounter domain-impacted information, like "is this a valid ID in our database" that a schema rule can't encode. Because JSON is so readily deserialized to, at a minimum, hashmaps and lists, it can be readily validated with code. Virtually all JSON deserialization libraries also provide the ability (in typed languages) to provide a desired type to deserialize into, and the type information of the member variables, even lists/maps, is decorated such that those can be deserialized as well. In that case, the JSON deserialization-to-type provides an automatic schema validator with no schema rules to maintain alongside the class specification. If you REALLY like XML because it kind of self-documents a bit better or stuctures better or ... well I can't really think of a reason why to use XML, but anyway I recommend YAML as a modern replacement. God I wish XPath was ported to json/yaml/toml land though. That was the bees knees as my grandma used to say.