Re: Use of XML for config files

[Darren New <dnew@san.rr.com>]

Georg Bauhaus wrote:
> 
> Ted Dennison <dennison@telepath.com> wrote:
> : What's wrong is:
> :
> : 1) It could be *far* smaller than that, if we were parsing a simpler
> : syntax.
> 
> far by what amount?
> <item key="the_key">value string of some average length</item>
> the_key:=value string of some average length
> 
> 2/3.

Ted was talking about the code being smaller, not the config file.

It is far easier to split a string at an = than it is to parse even
restricted XML.

> You mention real time systems, but I wonder whether a configuration
> for an AWS application will get anything but messy if it has to
> be configured with key value pairs only.

Yes, but it will be simple, and relatively easy to edit by hand, which was
the point. Every suggestion at something more complex than simple
string=string runs into the problem of editing it by hand.

> Ada equivalent: put everything
> in one big package.

Well, that's why the config file has sections and nested heirarchical names
and multiple config files per program.
 
> I don't understand this verbosity and design aversion in an Ada context :-)

The people editing the config file might not be Ada programmers.
 
> : I will cost us, in that it will make the file much harder for humans
> : to read.
> 
> Depends. (On the design of the (implicit or explicit) DTD.

No, it doesn't. XML requires balanced start and end tags, it requires quotes
in attributes, it requires that less-than and ampersand in PCDATA be
escaped, none of which is true for INI formats and all of which is true
regardless of the DTD.

> : I'm particuarly thinking of the site maintanence engineers
> 
> who could use _any_ XML enabled editing tool to write valid
> configuration files (where valid refers to XML validation).

Errr... as opposed to using 'cat' to edit INI files?
 
> : as its easy to forget an end tag or
> : transpose a letter somewhere.
> 
> the idea behind XML is that you don't have to write tags yourself.
> That would be the province of the XML application (e.g. editor) or

So why not allow binary in the files, if you need to use a special editor to
edit them? I think we're starting to go in circles at this point.

I think the question you have to answer clearly, if you're advocating XML,
is what benefit does it offer this project above and beyond the capabilities
that an INI-format file would offer?

> Should the decision between very simple Key(i) = value(i)
> and a grammar driven externally checked configuration be frozen
> in the API?

I think if you're looking for a simple config file API, then yes. If you're
looking for full-blown XML with namespaces and cross references and all,
you're looking at something best done with a full-blown XML parser, at which
point who needs a config file API anyway?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.