6 ms·
The problem is that XML doesn't even map that well even to objects and classes, even with annotation. And XSD is quite a heavyweight format with terrible UX. I
by unscaled 3y ago
The problem is that XML doesn't even map that well even to objects and classes, even with annotation. And XSD is quite a heavyweight format with terrible UX.
I'm pretty much consistently on the strict/type-safe side of the "should we have a schema" debate, but there are better options out there to maintain a consistent schema for either data interchange.
JSON is simpler to map, faster to parse, simpler, more lightweight, and less dangerous to add to an online app[1]. You can also use a schema like JSON Schema for inter-app compatibility. It has replaced XML as the standard data interchange format for a reason. It's not great for configuration files, and it's definitely being overused nowadays, but it is a solid data interchange format.
Then you've got binary formats like Protocol Buffers which are even more lightweight and faster to parse and (generally) have schemas that map better to typed languages.
I think the OP has it right: XML is very well-suited as a generic document format. I wouldn't compare it to YAML, because in a perfect world they shouldn't compete in the same categories: Nobody should use XML for configuration or YAML for documents.
And I also agree that there are better formats than YAML. I like the ease of writing indented multiline strings in YAML, but the fuzzy typing is pretty terrible. At least YAML 1.2 fixed the Norway problem.
[1] https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack
- chii 3y ago> JSON is simpler to map, faster to parse, simpler, more lightweight JSON is no simpler (nor more complicated) than XML, if you're using a library. It certainly isn't faster - a SAX parser is faster than a JSON DOM parser (and JSON streaming parsers equivalent to SAX is rare). > It has replaced XML as the standard data interchange format for a reason. the reason isn't technical. It's competency (or lack thereof). Most interchange formats are for websites in browsers, where JSON performs well, since there's no native way to parse XML in the browser. So that mindshare from the web has leaked out to other arenas.
- Ygg2 3y agoThat's crazy talk. JSON is very simple. The irreducible complexity of JSON is lower than irreducible complexity of XML, and irreducible complexity of XML is lower than YAML.
- wokkel 3y agoJson is simple, but the common idiom is to read it al at once into memory and forget the difficult stuff (which encoding is this json in anyway). Then don't do the other difficult stuff (is this a string or a date type)... so it's faster (maybe) to parse but it doesn't scale for large datasets and your application will need additional deserialization logic. A broad sweeping performance statement like this is just spreading fud.
- vaylian 3y agoJSON is hardly very simple given that is a subset of JavaScript. There's also problems with different behaviors of JSON parsers: https://portswigger.net/daily-swig/research-how-json-parsers-can-create-security-risks-when-it-comes-to-interoperability https://portswigger.net/daily-swig/research-how-json-parsers...
- Ygg2 3y agoConsider that YAML is superset of JSON. Then realize any Yaml parser suffers from JSON faults+ YAML unique faults.
- wokkel 3y agoRegarding security: entity expansion bugs have been fixed long ago. In the other hand: people still use eval() on json objects to parse them. So i don't get that. Json schema: which one? Afaik it's not there and there is no single json schema with the tooling depth and breadth of xsd. Protobuf: nice but unreadable for humans. Might as well use corba or asn.1 coding.