XML might work if it was well-formed and laid out neatly as per a custom DTD, but that's just extra hassle for the sakes of getting XML to work.
Furthermore, I have seen some weird XML configuration files that go along the lines of this (forgive me if this isnt valid XML, it's only a crude example).
<file1 perms="rxwrwxrwx" contents="invoices for the month of may">/pa
<file2 attributes="hidden from floor staff" expires="Mar,2007" conten
+ts="company downsizing plans">/path/to/some/file2<file2>
That opposed to the micro$oft .INI fmt
contents="invoices for the month of may"
Attributes="Hidden from floor staff"
contents="company downsizing plans"
The latter not only looks neater, information is easily gleaned out of it when a human reads it. Less is likely to go wrong with it too, IMO and (Tongue in cheek) it also takes up less disk/memory space. :)
Well, I'm a fan of XML (for various reasons) if it's machine-generated and machine-read, I'd consider it in in-house config-files (as long as staff were XML-savvy), but if I wanted to save support staff the headache of dealing with an external XML-unsavvy user, I'd use .INI or something along those lines. XML is just not worth the hassle if you are going to have other people meddling about with it.