For my sins I use to work with a complex and often evil Content Managment System. Depending upon which OS you were running the configuration was stored in different structures. On Windows it wrote to the Registry and on Solaris it wrote an single XML file to the file system.

In normal use the application read and wrote it's own configuration setting, and users never touched the configration directly. When this worked, it worked fine the system started okay, ran okay and stopped okay. So in an ideal world I don't think it matters what you do, as long as your applications know what they are doing.

When things went wrong, it required a manual hack to fix things. Working on the Windows registry was something our customers were very unhappy to do. They worried that they would break everything. The simple XML file had it's advantages, over the more complex Windows Registry solution.

I find XML easy to edit by hand, and I use a dedicated XML tool, so I know if the file is well-formed, and if I'm lucky valid. Many people don't have the luxury of dedicated XML tools, and so I lean more towards a simpler text - if you expect people to edit them by hand.

What I would recommend more than anything else is the ability to run a sanity test of the configuartion file. One of our products wouldn't start if the XML file was invalid, and because the XML file was invalid, it wouldn't log that there was a problem with the configuration file. Apache has it's "-t" option which is most useful in testing that there is a config file, it can read it, and it's syntatically correct.

In my experience it doesn't matter how you do it when it works, but when it breaks you may need a solution that you can fix by hand. XML is okay, though it's not everyones cup of tea...

my 2p

Good luck....