I'm extremely underwhelmed with Apache style configuration files that appear to be loosely based on XML but quite clearly are not valid XML.
 
I expect, (but don't know the history) that Apache steered clear of requiring valid XML because it would require some compromise to human-readability of the raw file. (because you can't rely on preservation of whitespace/formatting)
Also - when the Apache team chose their format - I guess XML processing tools & libraries weren't anywhere near as mature and widespread as they are today.
 
You could have both valid XML and maintain some human readability by (where practical) using subnodes for attributes
instead of having extremely long lists of attributes on any particular node.
e.g
<somesection>
  <parameter>value</parameter>
 <parameter2>value</parameter2>
 ...
</somesection> 
 
Requiring the entire file to be proper XML would provide benefits as far as responsibility-partitioning, extensibility, and flexibility in the use of configuration tools.
 
If there is general agreement that this is a good direction to head, then getting this sorted out early on will help in terms of providing a better ability to configure modules independently of each other and of the main config settings.
 
 e. g A chunk of XML (or its DOM representation) could be more easily passed off to the relevant module to handle it's own initialization.
 
I'd love to see 'configuration file format' as one of the first items for discussion regarding Yaws 2.0 - as clearly the decision on which way to go with this (if at all) could affect most other code development & tidy-ups.
 
Julian Noble