Re: Use of XML for config files

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

Georg Bauhaus wrote:
> Uhm, you have named the things to consider for a policy. Have I missed
> something? Merging, overriding, combining, how should that appear in
> an API independent of any file format?

Well, that's the question. I think it's something much easier to answer for
INI files than XML files.

> : It sounds like by using XML, you're introducing all kinds of ordering
> : dependencies in the file,
> 
> No that is introduced by using comments as data and has nothing to
> do with XML.

Uh, sure it does. The order of tags in XML is quite explicitly important.

> :treating the database as an XML structure rather
> : than something closer to a hashtable,
> 
> Yes. That is what I would like to see. Something that is different
> from but including lookup tables.

Well, propose something. :-)

> : Difficult to do, in the case of comments.
> 
> Independent of whether pairs are stored linearly ordered in INI file
> format, or in XML, no?

Difficult to do if you use XML, because XML has a particular semantics for
comments. Easy to do for INI because you get to make up yourself what those
semantics are. In an INI format, I could say "the comment always attaches to
whatever non-comment object comes next." So you'd have

# This section is for colors
[Colors]
# The background color
bg=23
# The forground color
fg=87

Here, if I used the API to delete "fg" and wrote it back out, it's obvious
what happens to the comment. 

In XML, I could wind up with comments most anywhere, including multiple
comments attached to the same object, interspersed with "real" tags, where
you'd expect the comment to be about the tag. Unless you're proposing that
the above would translate to
<colors>
  <!-- This section is for colors -->
  <key name="bg">
    <!-- The background color -->
    23
  </key>
  <key name="fg">
    <!-- The foreground color -->
    87
  </key>
</colors>

I guess that's not too bad, but it does seem like overkill. And of course,
then you wind up with the possibilities of something like
   <key name="brush">
     <!-- First the name of the brush -->
     round airbrush
     <!-- Then the color -->
     green
     <!-- You can pick alpha blend modes here too -->
   </key>

I'm just saying that I think the semantics of the kind of thing an INI file
would have to deal with in the API are pretty darn straightforward. The
kinds of things an XML-based file would have to deal with are far more
complicated. XML is tremendous overkill for an INI-like API. I think many
people arguing against XML don't understand how it would particularly help
an INI-like API. Perhaps offering an idea of the API you're envisioning
would help it move forward.

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