Computer programs that are complex enough to do something interesting usually need to be configurable as well. That is, they must be capable of exhibiting variable behavior based on externally supplied parameters. An example of such variable behavior is operation in "verbose" mode vs. "quiet" mode. Back when we all had access to command lines, you could specify verbose vs. quiet behavior as a command-line option. But assuming you can even find a command line today, it is not practical for specifying more than a handful of parameters. Enter the problematic configuration file.
The world of configuration files is one of ceaseless invention and chaos. I myself have, over the years, invented dozens of configuration scripts for various programs. Each of them is sufficiently clever (read: different) to be incompatible with the others. I know I am not alone in this self-defeating form of creativity. Early Windows programmers had to contend with at least three different script formats. There were resource files, module definition files, and .INI files. I have often wondered why Microsoft — with its seemingly endless initiatives to "unify everything" — could not have unified these simple script formats around a common grammar. Alas, the right hand kneweth not what the left hand wath doing, or so it seems. Today there is hope, not just for Microsoft, but for ordinary programmers as well. I believe that much of this chaos has been due to a lack of standards. Sure, we've had more-or-less standard scripting languages (Perl, Awk, etc.) for years now. But these are procedural languages; they want to do something; they're not really suitable for describing static data. Now we have a language that is up to the task. I am speaking, of course, of XML (eXtensible Markup Language). For a nice introduction, see Sebastien Andrivet's article, "A Simple XML Parser," on page 22. Before you write off XML as just another buzzword, consider that it is precisely XML's buzzword status that makes it suitable for our purposes. While perhaps countless wonderful configuration formats have been devised over the years, they have all lacked one essential ingredient for widespread adoption, an ingredient that XML has in spades — publicity. Note that we need not concern ourselves with the entire XML language, which is breathtakingly complex for a non-executing language, and whose more esoteric features are still being hammered out in committees. A small, stable subset, such as utilized by Andrivet, will suffice as a configuration format. Note also that we need not care whether XML proves itself technically fit to become the "metadata language of the enterprise," or somesuch rot. Its suitability as a configuration format is self-evident. My main concern is that programmers adopt it as such while it is still popular. (That is not to say that XML is going away; but you never know.) We've come a long way from the days when the only language "real programmers" used was assembly language. With each increase in processing power, we've been able to write programs in more human-friendly terms. Today, unless you are doing something special-purpose, there is no excuse for writing cryptic code just to squeeze a few more cycles out of the CPU. Likewise, there is no longer much justification for using miserly binary data formats when a human-readable text format will do. XML represents a nice compromise between readability and efficiency. The next time you need to come up with a configuration format, give XML a whirl. It will give you a cool buzzword you can use on your boss. It should make your code easier to reuse. And if that's not enough, consider your fellow programmers. Using XML will spare the world one more clever format it probably doesn't need.Marc Briand
Editor-in-Chief