[cm2187]

In all fairness, 99% of the time you will use a library to serialise and deserialize. So I always found this xml vs json debate a bit sterile. As long as it is possible to inspect the file visually ocasionally, they're both good enough. I don't know anyone who edits manually huge amounts of xml/json, and if they do, there is probably a better way.

[jcrawfordor]

One consideration that's worth thinking about is that XML serialization is larger (often not insignificantly) than the same data serialized as JSON.

On the other hand, XML can make error handling much easier by schema-validating received documents and thus rejecting a large class of invalid inputs at an early stage. This is particularly helpful if you're making something interoperable, like a public API.

So even when you're just using a library, there are ramifications to the decision.

[cm2187]

Correct. But in the order of things I care the most about, using angle or curly brackets matters a lot less than problems like: can I serialize multi-dimensional arrays, dictionaries, arrays of bytes, etc.

[__david__]

And 99% of the time the JSON serialize/deserialize library is much simpler and straightforward than the XML one, especially if your language has native hashes and arrays.

There's also a bitter taste in many of our mouths left by the "XML All The Things!" crowd that brought us such monstrosities as Maven config files and XLST.

[cm2187]

XLST is useful when you want to change an Xml configuration file based on whether you are in debug or release mode, without having to duplicate the whole thing. But I wouldn't hold it against Xml, you only use it if you find it useful.

[__david__]

XLST the language is great. I love the idea, it's wonderful and powerful in practice.

XLST the syntax is an abomination. Trying to shoehorn a language syntax into XML was a stupid, stupid idea.