Re: Use of XML for config files

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

Darren New <dnew@san.rr.com> wrote:
: the order of tags in XML is quite explicitly important.

Unless the DTD says it doesn't matter (in repeated alternatives).
(Otherwise it would be impossible to have mixed content, like for
example emphasized text before or after a code sample in an HTML
paragraph).
SGML is more convenient in this respect, since it has not only
comma and bar for sequence and alternative, but also ampersand (and)
for "all in any order" in content models.

: Difficult to do if you use XML, because XML has a particular semantics for
: comments.

None that I know of. You can put pretty much anything in a comment other
than --.

: "the comment always attaches to
: whatever non-comment object comes next."

Why shouldn't that be possible with XML?

               parent
         /    /       \      \
    child1 comment2a comment2b child2 ...

: [...]
: I guess that's not too bad, but it does seem like overkill.

XML _is_ verbose, and I've come to like some verbosity :-)

: XML is tremendous overkill for an INI-like API.

It sure is. But...

: I think many
: people arguing against XML don't understand how it would particularly help
: an INI-like API.

This isn't what I would want it to do, it should (if necessary) help
overcome the limitations of sectioned key-value settings.

: Perhaps offering an idea of the API you're envisioning
: would help it move forward.

Suppose an INI-like API would cover sections and key-value settings
in a section, using any syntax. Then in your example you might have

[tools]
brush=round airbrush green
...

(Maybe you would do it differently?)

This leaves some room for parsing, in that you would have to specify
1st is shape, 2nd is type, 3rd is color.

whereas
<tools>
  <brush type="airbrush" shape="circle" color="green"/>
  ...
</tools>

makes this unnecessary. Much like named parameters in Ada.

In addition, as you can see in the example,
I am thinking of an application which (perhaps unlike
other applications) might profit from tags that do not just
mimic INI-style "key" and "value". This makes the configuration
look like application specific, but why not? The software for
fiddling with the configuration data doesn't have to be, except
for the necessary parameterizations of subprograms,
say (for example if you want the attribute list of the current
tool, which is a String = Name_Of(Brush)).

Of course, building the software for access paths in configuration trees
might not look as straightforward if all the XML handling has to be
invented. But a lot of effort has already gone into building XML
software, we only need to reuse it :-)

I like TED's idea of child packages, but have to think about this
some more.