Re: Use of XML for config files

[dennison@telepath.com (Ted Dennison)]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkbsakqfiw.fsf@acm.org>...
> dennison@telepath.com (Ted Dennison) writes:
> > What that means is that if we were to use XML, we should support
> > both user-defined configuration item attributes 
> 
> Just because XML supports this, doesn't mean the Config_File API
> should. We're looking for a simple subset. If the app decides it needs

I'd agree with this statement. However, I'd take it one step further:
Just because we *could* use XML doesn't mean we should. We have other
simpler options than XML. Supporting the more complex syntax of XML is
going to be a burden on both package implementors and config file
users. We shouldn't be imposing the extra burden unless we get
something good in return that we won't get with a simpler syntax.

> > If we are to stick with simple attribute-value pairs, then XML would
> > be major overkill.
> 
> In what way? I have a very small package that parses the subset of XML
> that I need to meet the Config_File spec (Glib.XML - 671 lines in the
> body). What's wrong with that?

What's wrong is:

 1) It could be *far* smaller than that, if we were parsing a simpler
syntax.

 2) Its going to cause an explosion of arcane-looking XML cruft in the
config files, the vast majority of which is unneeded, except that XML
says it has to be there. What's the point of saying
<item><key>...</key></item> all the time, if *everything* is an item,
and key is the only attribute we ever use?

I will cost us, in that it will make the file much harder for humans
to read. I'm particuarly thinking of the site maintanence engineers
who are the typical users of real-time system configuration files. It
also adds a source of errors, as its easy to forget an end tag or
transpose a letter somewhere. You really whould have trouble doing
that if your only syntax is "=".

So again, I think its an important point that we should only do this
to ourselves if we are getting something back that we can't get out of
a more simple configuration file format.