4 ms·

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 c

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.

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.