Re: Use of XML for config files

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

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

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

If you are modifying the INI file format by adding "." to keys, that's
not the INI file format, and we might as well use the Java property
format (which I did in my latest implementation).

Please look at that and see if you like it.

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

Yes.

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

I didn't implement this, but it is in the requirements (return a list
of the next-level items at a given level).

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

I see the distinction, but I'm not clear when it is relevant. Since
the application has to know the name and type of everything in the
config file, it knows what to ask for all the time.

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

Requirement 16; data retrieval is independent of the key order in the
file. So the in-memory copy of the data has to group all the brush.xxx
values together; I used a tree structure.

> You whould have to keep track of them all, afaics, in a sorted map?

Yes, or a tree. Some sort of ordered structure is required.

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

That is a requirement on the file format. But we actually need a
requirement on the in-memory copy. That turns out to be easier.

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

Requirement 17; multiple copies are allowed on read (last one is
saved). Only one is written.

Presumably, when the app writes the config file, it will be properly
sorted and/or grouped.

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

Yes, I'm not clear whether we should allow/require multi-line values
with the Java properties format. I would hope that there are no
"overly long values" in a config file. In general, my approach to
binary data like pictures would be to put the path to the picture file
in the config file. Do you have an example where that is not the right
approach? 

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

I'll settle for novice-proof :). Clearly, it is harder to screw up the
Java property syntax than the XML syntax. We have to assume some level
of competence on the part of the user.

> How are the configuration values stored internally? In a hash table
> indexed by dotted names? 

It's up to the implementer. The API requirements don't actually say,
but my example implementations say keys are dotted names, and the
internal format is a tree.

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

Yes. Although if you use a hash table on the full key, you are not
"parsing", you are "hashing".

My implementations do "parse" the keys for each lookup. That was easy
to do; if it turns out to be to slow, somebody can do a hash table or
something else.

> If the values are stored in an tree, wouldn't this effort in effect
> start building DOM support for INI files? :-)

Yes. I think that's implied by the current requirements.

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

I prefer one standard file format, so different apps can share them,
and people get used to editing one format, and the implementation code
gets tested more.

If your app outgrows the Config_File spec, and you need XML, you can
convert the files once, and start using a real XML parser.

-- 
-- Stephe