Re: Use of XML for config files

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

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
: Can you give more detail about what is missing?
: not clear what operations are implied by "administer". 

"administer" was just a very bad choice for a word, please
forget.
There is one thing that isn't missing but--from some
perspective-- might be too much.  (So I could just not use it
and be done with it, of course, so what? ) There are generics for
read/write of several kinds of types.  But the API could as well
shift the responsibility for interpretive reading and writing
of textual and Ada representation of data to the application,
or another package. (That's not a new thought I guess?)
For example, it might be that different people have different
habits for writing floating point numbers, e.g. money values,
percent character, etc.

: I guess "de_CH" is a language specifier?

Yes, maybe not following the most recent standard, but still valid
(and also present in the XML lang attribute).

: Although it would be simpler to have a separate config file for each
: language.

Yes but I would have to keep the few in sync.  (Scenario: An
application reads data that identifies itself as beeing intended
for readers of French, or Italian, or...  The configuration has
the respective currency symbol, month names, special things as
required by corporate identity...)

: 
:>   where the text of the explanation is written by non-programmers. I
:>   can now, but my conf keys will look like x.y.de_CH, x.y.fr_FR etc.
: 
: Why is that bad? Your code would be:
: explanation (property (x, "y." & Current_Language));
: Not much different, and makes the standard Config_Files library much
: simpler.

It's not at all bad in an application program. 
(The only time I was worried about x.y.de_CH used as a key _in
the application_ was when de_CH is not unique as it is here,
but needs to be named. But this can be done by introducing
another section, x.y.lang.de_CH.)

: Um, what do you mean by "internal"? In both of my proposed specs,
: the user must specify "x.y.de_CH". The keys are visible.

I mean that I could possibly map "x.y.de_CH", or with the above,
"x.y.lang.de_CH" to either it's identity in a properties
file, or to <x><y lang="de_CH">...</y></x> in an XML file.
I'm fiddling with this and XML/Ada using the already present
DOM representation and the Config_Files interfaces.  Would it
make sense to bring Grace.Config_Files_* to another hierarchical
level so the interface (e.g. as specified in Config_Files_Java)
would be implemented in different ways in child packages?

: The Config_Files requirements assume that everyone is "familiar" with
: simple text editors. If your users are not, then you should not be
: using Config_Files, or you should provide a different tool for the
: users to edit them with.

Yes, exactly that is one of the strong arguments I see for
XML support. (Perhaps) optimistically, all I have to do is to send
them a suitable DTD, and a validating XML editor.
I won't have to write an application that
sets everything up one their computer so they can write relatively
sane configuration files. (not sure whether this is applicable
for the average Ada program users, so maybe not an issue.)

:> Well, OTOH, file formats do have consequences for what you can reasonably
:> want to be present in an API don't they?
: 
: You have said exactly the opposite, just 17 lines above.

Uhm, I said "it should look like", there is a difference :-)

-- Georg