I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file.
In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do).
I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".
>In those cases, I would rather have XML config files than undocumented binary blobs as config files.
False dichotomy.
Better than XML and binary blobs:
* JSON (assuming everyone knows what this is)
* YAML [0]
* Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all)
* INF format [1] (not my favorite, but pretty easy to parse and much better for humans to read than XML)
* Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days)
Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language.
I seriously think the lack of comments is a deal breaker for JSON config files for me. At least with what I'm doing now. I find myself changing configs a ton, and I love being able to simply change which blocks are commented to get what I want, without having to dig anywhere.
JSON5 [1] is an extension to JSON that allows comments, multi line strings, additional commas at the ends of lists, and more. It has become my preferred config file format.
You can use Protocol Buffers for configs without having to serialize them in its binary format. Protocol Buffers has always had its own text format [0] and now a JSON mapping [1] as well.
The proto text format is actually more flexible and less verbose than JSON since it does not require the outer enclosing set of braces and quotes around all the keys and has support for comments.
Here are a couple of examples of config files using the Protocol Buffers text format:
GP is obviously not stupid enough to think that XML and binary are the only options. Their whole point seemed to be that they've seen enough binary blobs in practice that even XML was a welcome step up.
I've always considered YAML to be far too complicated. There are many overlapping/redundant syntax rules for doing the same thing, lots of ways to mess up parsing, etc.
I'd say TOML [0] is the best because it can be a very simple key=value structure, but also supports very detailed, nested structures. It has a 1-to-1 correspondence with JSON, but is more friendly for configuration (comments are a huge help!)
I've mostly come across XML config files that are meant to be edited by humans in various programs that use some kind of Java framework as the back-end.
I don't Java much, so I'd be hard pressed to remember the various framework names (Spring maybe?) but I remember at one point writing a Python script to de-XML the config files into something that was just a bunch of key=values, then another Python script to convert it back to the required XML. IIR on that project, the handful of config options that needed to be tweaked were spread across a dozen or so different XML files.
If the framework could have just read a .txt file with key=values in it, config changes would have gone from 10 minutes to 30 seconds. I eventually just wrote a python thing that auto-deployed and configured the entire stack after asking you a couple questions.
It was absurd.
I believe Android development does (used to?) require lots of hand XML editing. Most of which just drives a Java code generator. I guess the tooling is better these days, but it was enough to drive me away.
Spring was certainly a very XML focused framework.
However it has had for a long time ways of using property files in conjunction with XML, while you would still need the XML to define your dependencies, you could have a simple property file for runtime configuration.
Thankfully in newer releases and with spring-boot you can avoid XML entirely.
Config files are usually plain key-value pairs and, of course, using a whole eXtensible Markup Language for them is kind of overkill. But if your config files are more complex, say, you need a Makefile-like stuff, then XML is more than appropriate.
>> I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly
I think it's more like, it's a text format (no matter what the op recommends) so it can be edited. If you don't want anyone editing your configuration you don't store it in a text file, right?
Not to mention stuff like pom files that are explicitly meant to be edited by hand. Gods, why?
In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do).
I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".