4 ms·

The problem is that XML is a markup language, which is entirely incompatible with the way data is usually structured in programs. Your example is simple enough

The problem is that XML is a markup language, which is entirely incompatible with the way data is usually structured in programs. Your example is simple enough, but consider the following: <root> This is some text. <type1 attributes="yes"> This is content with <i>markup</i>. </type1> <type1> Another element of the same type. </type1> <type2> And this is an element of an entirely different type. </type2> This is more text. </root> How the hell can I map that to my data model? My application data will, at worst, be a graph of class instances with named fields, containers (lists, sets, etc), and primitives (strings, ints, etc). The fact that XML has both attributes and subelements is already a huge impedance mismatch because classes have a single namespace. But what do I do with the repeated element? With the text interspaced with tags? What's the API to navigate this mess? I'm pretty sure that's why JSON won: it started from the application data model and just simplified it (no custom types, trees only). A deserialized JSON object doesn't even need an API, it's just a nested structure of built-in types found in any modern programming language.

ivan_gammel 4y ago
This is a made-up problem that never existed in reality. On practice if you have to deal with a mix of text and elements, it is always deliberate and explicit choice which probably makes sense. In my decades long career I have never seen it, so it must be a rare case. You ask about API: XML mapping problem has been solved more than 20 years ago and standard cross-platform API exists since then. Have you ever heard of DOM? Have you ever heard of data mappers? XML Schema-based code generation? In modern Java you can even use the same mapping both for JSON and XML. There are two reasons why JSON dominates in certain applications: easier to write a small structure, browser-friendly. XML still has advantages in large datasets and schema validation.
- AtlasBarfed 4y ago
  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.

ivan_gammel 4y ago

This is a made-up problem that never existed in reality. On practice if you have to deal with a mix of text and elements, it is always deliberate and explicit choice which probably makes sense. In my decades long career I have never seen it, so it must be a rare case. You ask about API: XML mapping problem has been solved more than 20 years ago and standard cross-platform API exists since then. Have you ever heard of DOM? Have you ever heard of data mappers? XML Schema-based code generation? In modern Java you can even use the same mapping both for JSON and XML. There are two reasons why JSON dominates in certain applications: easier to write a small structure, browser-friendly. XML still has advantages in large datasets and schema validation.

AtlasBarfed 4y ago
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.