Re: Use of XML for config files

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

dennison@telepath.com (Ted Dennison) writes:

> > > 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.

Um, I don't see how. That's 671 total lines, comments and blanks
included! Basically, it's a recursive function, looking for matching
<tag></tag>. Really simple.

I suppose if I used OpenToken or something, the top level file would
be smaller. This file is built on top of Ada.Text_IO.

>  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?

The file I'm currently generating doesn't look like that; it really is
very simple. I posted a sample yesterday. I'll post a full trial
implementation sometime soon.

> 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 "=".

These are valid concerns. But I think you misunderstand just how
simple the syntax generated by Glib.XML really is. 

Of course, it may be that it is not valid XML.

> 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.

Yes. I agree.

> 

-- 
-- Stephe