Why XML is terrible for configuration files
February 28, 2010
There's a lot of things that get called 'configuration files', so I want to be specific that I mean the sort of configuration files that have three primary uses: they're written by people, used by programs, and later read by people who are trying to figure out what the programs are set up to do. These are the kind of configuration files that XML is terrible for.
(There's a whole ecology of 'configuration files' that are generated by one program and consumed by others, and are pretty much never touched by people. I don't care what format they're in, and there's perfectly sensible reasons to use XML for them.)
The reasons that XML is terrible for configuration files are right there in the description of what these sorts of configuration files are for. The only one of those three things that XML makes easy is being used by programs; XML is famously difficult and annoying to write by hand and equally hard to read (partly because it is so verbose; excess verbosity causes people to lose track of where they are). Common ways to structure data in XML files make this even worse because they tend to be designed for the convenience of programs, not to be comprehensible to people.
General XML editors improve the situation somewhat but I feel that they don't really do all that much for making it genuinely easy for people to write and read XML. This goes doubly so if your XML format has data structuring issues.
XML is also prone to a particular disease, which is best illustrated by asking a question: is your XML format actually documented, in full detail, in a way that is at least as good as the Atom feed format specification or the description of your favorite program's regular configuration file? All too often the answer is that it is not, because people have the peculiar impression that using XML with verbose element and attribute names plus some sketchy documentation is sufficient.
(Please note that a DTD is not documentation. Try again.)
This issue cannot be solved by creating a nice user-friendly program to create and maintain the XML configuration file. If you do this, what you have really done is created a program without a real configuration file that is instead configured only through an GUI interface. And you still have the documentation problem; it's just that you now have to document the effects of the program instead of the configuration file.
(For bonus points, this configuration process is generally asynchronous so you can't immediately see the effects of your configuration changes.)
Comments on this page:
* * *
Atom feeds are available; see the bottom of most pages.