In Defense of XML
Nicolas Fränkel (via John D. Cook, Hacker News):
Ever since then, it would be an euphemism to say XML has been losing in popularity. Other formats, such as JSON and YAML, have replaced it in the hearts of developers. In this post, I’d like to:
- Explore some of the reasons why the mighty XML has fallen
- Raise some downsides of the popular alternatives
- And describe how XML already solved those problems
3 Comments RSS · Twitter
Dillan: "Also, try handling merge conflicts in git with XML or even JSON to some extent. In those cases, YAML wins hands down."
Disagree. XML allows you to include one file in another, so you can break up your mega.xml into pieces of reasonable size. JSON and YAML don't support that. Sure, some programs may allow multiple JSON/YAML files in some cases, but it's not part of the file format, and not common.
(I would call this part of "Composable", which is mentioned in this Defense, though the author doesn't specifically call out this aspect of composability.)
Being able to use separate files for separate sections is table stakes for sane merges. You avoid most conflicts in the first place if you're not all editing the same file all the time. I don't love XML but that's one thing it got right.
That is fair if you are doing direct XML editing. In our case, XML is the data format for a GUI app we use (Freeplane), and I am not sure if we could get it to play nicely with that mindset. Most of the developers prefer writing the YAML files over the GUI editing anyway.
But yes, if you are working directly with XML, that is a much cleaner way to proceed.
1. StrictYAML if you want more control over your YAML
2. JSON Schemas exist
3. JSON5 exists with comments
4. XML is not fun to write. From an end-user perspective, white space languages are much more desirable. At my job I have the users write requirements using YAML because it easier to write. Also, try handling merge conflicts in git with XML or even JSON to some extent. In those cases, YAML wins hands down.