Re: Use of XML for config files

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

Darren New <dnew@san.rr.com> writes:

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

I agree with this; I'm not sure how to put comments in the API.

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

Ok, could you provide an example implementation? I'll be posting a
Java properties style after the weekend, without comments. Maybe you
could start with that.

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

Well, the order of data tag 'foo' vs comment tag 'bar' is not
important, unless the DTD says it is.

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

But we don't _have_ to use that for Config_File comments. I think
Config_File comments as attributes makes the associations easier to
keep straight. But it would probably be somewhat confusing to read :(. 

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

Ok, I like that. It breaks your earlier example where you had a
comment following a value, but we can't have everything.

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

I bet we could come up with an implementation of the same semantics
for XML.

Note that neither of these semantics will support arbitrary placement
of comments by direct editing; the user has to know the rules.

> The kinds of things an XML-based file would have to deal with are
> far more complicated. 

But we don't have to support them all.

-- 
-- Stephe