The Benefits of XML Config Files (and why I don't use them)

XML configuration files are almost always the smartest way to handle configuration information. I’m about to do (and post) some stuff that DOESN'T use them and rather than waiting for everyone to tell me all of the benefits I’m missing, I thought I'd post them upfront (feel free to add any benefits I’ve missed) so it is understood that this was a choice, not an accident. Maybe a bad choice . . . :->

Validation
As long as you have a DTD/Schema for your XML, you can validate XML against the DTD/Schema to confirm that it meets the specificed requirements. This can be extremely useful in pre-checking your data before getting a ColdFusion error because your configuration data was not well formed. Better yet, you don’t need to write any of the validation code – just the DTD/schema.

Manipulation
With XSLT you can transform XML files from one structure to another and you can even query the data using XPath. There are lots of great tools for working with XML files and again, they’re just there. You don’t need to write them.

Editing
There are plenty of good free plug ins for Eclipse and stand alone editors (XMLBuddy seems to be a popular Eclipse plug in). People are mostly used to editing in XML and there are good tools with highlighting and that will validate against a DTD/Schema in editor.

Consistency
As in Steve Krug’s “Don’t Make me think”, framework design choices should bear in mind that many people spend most of their time using something other than your framework. I may not use MG often, but apart from learning the vocabulary of the DSLs, there is no real learning curve in terms of how to create an XML config file for Reactor, CS or MG. Same for Mach-II and anything else that uses XML configuration files. It is usually better to do things the way people expect so they have less to learn.

So What is Wrong with XML?
Nothing at all. It isn’t terribly performance compared to something tighter, but for configuration information that is almost completely irrelevant. I find a high signal to noise ratio (quite a low expressiveness in terms of number of characters required to communicate something compared with a custom language or a tight configuration file), but again, disk space is cheap and you can always cut and paste. I can’t ever imagine someone giving up Reactor because it took them too long to write a few lines of XML!!!

So Why Don’t I use it?
Partly I just don’t love tags (yeah – and I’m programming in ColdFusion – go figure). Partly there is the overhead of having the XML parsing code. The overhead is small, but I’m stripping every single thing out of my code (as you’ll see in my postings). Then later I may add it back in. Also, I keep all of my config information in a database. This would be a crazy choice if I was building a handful of projects, but my goal is industrial reuse – an assembly line for churning out thousands of custom web applications in minutes – not months. I have all of my validation rules and proving algorithms (well, I’m working on them) operating on the data as it is entered into the DB and I can do many cool dependency checks that’d be much harder working with static files.

So, for me I would have to take the metadata from the database, generate XML files, and then implement an XML parser to get that data back into a format I can use. It just doesn’t make sense. So, for now I just set a bunch of variables as that it easy to set and removes the runtime dependency from the metabase and is mindlessly easy to generate and use. I’ll probably replace it with something smarter over time, and if I ever want to seriously share this code (recommend it as opposed to just providing it) I would probably add optional support for XML configuration files, but for now, I just don’t have the need. Too many other itches to scratch!