First of all, Rob, I suggest that you prepend abstracts to emails which exceed 50 lines (maybe that should be 100, I dunno). How about 8 line abstracts, with each line under the standard 76ish character limit? :) You can even do <abstract>I demonstrate the necessity...</abstract> if you want :) My take on xml is that it should usually be used IFF the primary purpose of the data is to be read and written by machine, but human reading or writing is considered valuable (but secondary). The gconf stuff would be a perfect example. Let me try and summarize your five points: a) a standard config format would be good, and xml would be a good choice for that b) xml is well understood, other formats are inconsistent (maybe this should be a.1) c) xml is extensible, or MUCH easier to make extensible than most hand-rolled alternatives c) [ you probably meant d :) ] xml is easy to edit by hand d) easy multi-purpose parsing and machine-editing Basically, this comes down to a matter of opinion, but I think the place where I disagree is with reason c, (the second one). I think a lot of people find xml harder to read and edit than most other standard config files. I find I often have trouble finding the data amidst all that markup. This is just plain subjective, so I don't see much point in discussing it into the ground. However, it's often the dealbreaker for me. If I found xml as easy to read/edit as the standard .ini format (like yum uses) then I would be completely with you. After all that, let me finish with this: I don't have an opinion about which format should be used. I don't know enough (haven't been following closely) about what it will do, how it will be used/edited, and how extensible it needs to be. I just wanted to share my thoughts on Rob's thoughts on xml :) And to pick on Rob a little. I wanted to do that, too. -Michael -- Michael Stenner Office Phone: 919-660-2513 Duke University, Dept. of Physics mstenner@xxxxxxxxxxxx Box 90305, Durham N.C. 27708-0305