Re: Use of XML for config files

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Darren New <dnew@san.rr.com> wrote:
: val := conf.get("Section", "super.subkey", "default value goes here");

Fine except that you make a decision to limit us to
no subsections unless you allow "Section.Subsection"?
A la

  section_specification ::= section_name { "." section_name }

:  I'm
: trying to see what XML would be supporting that you can't support easily in
: the INI format.

(I'm guessing that if we go on, you would be demonstrating
that by building special syntax into the keys in an INI file
you could do pretty much anything that can be done with XML? :-)

Actually I'm fond of something like restricted XPath expressions.
They need not necessarily look like XPath expressions, I'm thinking of
a 1:1 mapping, if the (hidden) mechanism uses XML. This way we
could have a sectioning depth as needed by the application, but it
would always look like a dictionary lookup.

Unless I want all configuration data for one subsection or one
item, for which see below.

For an example of what cannot easily be done in INI format,
the distinction between values that are in fact
properties of items (like in the brush example) and values
for "stand alone" items (to me) are not really explicit in k=v, unless
the dot has this meaning. But when does a '.' have this meaning?
For example in a.b.c, what meaning does the first dot have
what meaning has the second? Aren't you introducing context
dependent meanings of the symbol '.'?

How many lines would you have to read for brush.xxx?
How do you know that when you have found brush.xxx lines
and the pen.xxx  lines, there will be no more brush.xxx
line after the pen.xxx lines? You whould have to keep
track of them all, afaics, in a sorted map? Or use
some equivalent mechanis.
If I use valid XML configuration data, then by previous validation
(if it has taken place), the brush node and only the brush node
below the tools node will contain all properties of the brush.

You cannot but by discipline require that there be only one
brush setting in exactely one tools section, can you? (That is,
the mechanics for dealing with conf data would have to check
this, which is another programming task for INI files, to some
extent mimiccing XML validation; this _could_ be different for
XML because you can couple your product with a tailored conf
editing component sold to your customer (such things exist :-)
See below for hand editing).

If conf values are big, will your customers be happy to have to
edit overly long lines? Would they be able to do that with
Wordpad? And without destructive effects? (I've 
elsewhere mentioned the problems induced by line breaks.)

OTOH, as Stephen mentions on his page, XML hand editing
requires knowledge of XML Syntax. But the issue (for me)
here is that you can get _any_ non-idiot-proof syntax wrong.
I doubt that there is an idiot-proof way of dealing with
this problem. (I'm not excluding myself from the set of
idiots here, I do use parsers :-)

How are the configuration values stored internally?
In a hash table indexed by dotted names? This would
require repeated "parsing", for example if I wanted to
write out anything having to do with brushes, since I have
to look for the "tools.brush" prefix. Right?
If the values are stored in an tree, wouldn't this effort
in effect start building DOM support for INI files? :-)

: So what are you suggesting the XML-based API should look like?

It should make no mention of XML, of course :-).

My idea is that ideally (o.K., whatelse is an idea! :-)
it is an option to choose a format and/or provide
for functionality to convert between them, if that is possible
(for example it is possible in one direction from INI->XML;
the opposite might not be easily done because applications
might have to be partly rewritten to cope with nested sections.)

-- Georg