In my experience, the things I would like to do as a programmer because they make sense to me cause the most problems for the non-programmers who have to use the stuff.

Some sort of config checker or lint is good, but XML isn't really going to do that for you. You want to check not only the format, but the meaning of the actual values (e.g. does that file really exist, can you send mail to that email address, etc). A DTD doesn't really buy you that much once you already have code to read the configuration and test it.

If techies will administer the app, then you might do just fine with an XML (or XML like) format. However, every time I think that, the maintenance task gets pawned off to some non-techie who just wants to make it through the day without breaking anything. :)

There's really no rule that fits everyone's situation, but I've found that the non-technical considerations to be more important, even when I didn't like it. :)

Just to add to this statement - our check-in process was recently modified to include a form to fill out with evidence that all proper processes have been followed. The form is just a text area field with pre-populated XML in it that we're supposed to fill in. Then the server validates each field, and, if anything isn't filled out appropriately, it spits back "invalid" for each field that's wrong.

I can tell you that this is seriously annoying.

And our product has a key selling feature that involves XML. And, obviously, nearly everyone using it are developers.

Although, on the other hand, it may make things a bit easier when I attempt to bypass the whole thing by writing a perl client that fills all the fields in for me, using LWP.

(I know this is straying dangerously off the original topic, but the lesson is: if you expect frequent modification, simple-to-edit becomes so much more important. And XML ain't it.)

Validation of the config file should only be a problem if it is not machine generated. If you are worried about validation then you are implying hand editing, and hand editing a large XML document is no fun at all! XML is, IMO, not suitable as a configuration file format intended for hand editing. Conventional .ini type files are much better in that regard and are generally pretty robust for parsing because their syntax is simple.

The underlying file format is completely independent of whether a file can be reloaded or loaded into a data structure. Many of the CPAN configuration modules do exactly that with a plethora of different configuration file types.

For persisting state where an application writes and reads the configuration files used XML can be usefull because it provides a somewhat human readable structure and there are standard tools around for viewing XML in a structured form. For exchanging information between different applications and using a DTD for mediation XML is very good. For large lumps of human editable configuration there are better solutions.

In this node I said that for large config files (a condition of the OP) that I preferred XML to many other mechanisms including oodles of name=value pairs.

The point of hyperlinking is to start with text that makes sense even without any hyperlinks, and then add links so that parts of the text magically take you to some place related to that text.

Misunderstanding this principle leads us to write "click here" style links, which mean nothing and actually detracts. Don't say "For more information, click here". Instead, write "For more information, see the detailed description". Not only will that read correctly in absence of a web browser (such as when printed), it even makes a somewhat self-documenting book mark: "the detailed description" vs "click here".

<xml>
<host1>
<hostname>foo</hostname>
<function>Serve intranet content</function>
<transport>TCP</transport>
<port>80</port>
</host1>
</xml>
[download]

[Host1]
Hostname=Foo
Function="Serve Intranet content"
Transport=TCP
Port=80
[download]

For me, though, I like the idea of being able to tell a running program (e.g. via a button or signal) to re-read a config file to cause changes to occur. It is nice if the file is externally validated before it is reread.

I prefer XML with a DTD because it can help prevent size=blue or color=large type mistakes...

You've said this multiple times, but you've never explained how.

The how is the same way you would do it for any other type of file. Someone writes a comprehensive set of rules by which to validate the configuration file. The file format doesn't matter. The format of the rules doesn't matter. Something reads and processes the configuration file and the rules and applies the rules to the processed file.

You have to do this anyway to parse the configuration file in your application.

Now you may have better tools to do this with an XML application than with any other format, but then your real argument for using XML is better tools, not validation.

And tools like this exist for formats like YAML; for example you can use kwalify to produce a DTD-like schema for YAML documents.

If the DTD is a tool, then yes, the issue is better tools. The way to do it in a DTD is:

<!ATLIST box color (red|blue|green) blue>
[download]

This allows

<box color=red />
[download]

but not

<box color=large />
[download]

The default is blue in this example.

If the biggest concern in this whole discussion is hand-editing of the config file by "non-techies", why not have a gui for editing the config? I understand the philosophy of allowing people to easily edit configs, but if we want to allow non technical users to make changes, maybe allowing them to directly edit a file by hand isn't the greatest idea.

Limiting the modification of the config file to methods provided by the developer eliminates the issues of validating the config at load time, and reduces support issues in the long run. I store my config data for Perl and C# apps in XML files, and have had no problems with the files being corrupted by an end user. If the user mucks around with the config files on their own, without making a backup first, and causes problems with the application, that is their own fault. They can recreate the configuration, or pay for my time to fix the file by hand.