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:

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

Ok.

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

They can do that now by writing to a string, and calling Write_String.
Or, we could add something like:

generic
   type Private_Type is private;
   with function To_String (Item : in Private_Type) return String;
procedure Write_Private
  (Config         : in out Configuration_Type;
   Key            : in     String;
   Value          : in     Private_Type;
   Error_Handling : in     Error_Handling_Type := Ignore);
   
I had that in originally, but took it out because it seemed to
encourage people to use a non-standard format in the config file. But
since people can get around that by just calling Write_String, maybe
it's worth putting back in.

Although I gather you are saying you'd be happy if I _only_ had
Write_String, without any generics.

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

Ok. So I think you agree the current spec is ok here, and we don't
need to add anything special for languages (or "localization" in
general). 

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

Well, yes, we could define a special support for languages in XML. I
don't see how it's worth it, in the Config_File context.

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

I'd like to have one standard file format. You can always add a child
package to implement a non-standard format. I wouldn't mind moving
enough of the body into the private part of the spec to make that
easier. 

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

Well, if you have a "validating XML editor" sitting around, that would
make things easy. I didn't think such things existed.

In the absence of that, I don't think it's very hard to build a
special editor for config files using the Java property format. Come
to think of it, somebody in the Java community has probably done just
that. 

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

The idea is that the installer for the app using the config file
writes a "sane" config file. Then the user can edit it if they need to
(like if their Windows disks get renamed). 

You do have to write the installer for your app.

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

Well, the goal is that the API is independent of the file format. If
we choose ini files, we can't have mult-level keys; that is one impact
on the API. Other than that, I have not seen any impact of the file
format on the API, given the other requirements on the API.

-- 
-- Stephe