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:
> : Georg Bauhaus wrote:
> :> Fine except that you make a decision to limit us to
> :> no subsections unless you allow "Section.Subsection"?
> : 
> : Yes. That makes it simple.
> 
> o.K. but I want more than exactely one layer of key hierarchy
> in my favourite API.
> 
> : But until
> : you say what it is you want, we're going to be arguing in circles, so I'm
> : not going to say that.
> 
> : [not] given the vaguest outline of what you expect your API to look like.
> 
> Speaking of trees and XPath gives several clues, doesn't it?
> I want to be able to address the following:
> - administer groups of related conf data (recursively)
> - administer individual conf items
> - administer properties of individual conf items
> All of this should be explicit.
> AFAICS this is present (more or less implicitly) in the
> "API requirements" section, and via "Dot" to some extent in
> Grace.Config_Files. 
> While we are at it: Thank You very much, Stephen!

You're welcome. Can you give more detail about what is missing? I'm
not clear what operations are implied by "administer". We have read,
write, delete, and list. What other operations do you want?

> Example: - multilingual settings for item x.y in [sec_a], so that,
> possibly after further abstraction in my application (though for
> simplicity I'd prefer access along one path in a conf tree), I can
> ask something like
> 
>     explanation(property(x, "y"), "de_CH")

I guess "de_CH" is a language specifier? That sounds like a neat idea.
Although it would be simpler to have a separate config file for each
language. Would you be changing language on the fly during the
program? I guess a "translator" program would. But then you could just
open both config files (the English one and the German one).

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

>   If the API freezes '.' for it's internal key strings, that's fine.
>   But I'm slightly worried that these won't make our customers happy
>   and that is why I'm glad that Grace.Config_files makes keys
>   internal, so our customers don't have to see them.

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.

> IN addition, I'd like to be able to "outsource" as much of
> configuration creation/modification as I can/must. But there are
> some constraints on this. Since our customers are largy unaware of
> text editting issues, I want to provide them with a tool that looks
> familiar, 

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.

> so when they use it it will provide us with relatively useful
> configuration data. (Some background (things that happen on the job
> (not just mine)): We ask for text only files, we get (at best) an
> RTF file of the latest MS Word kind. You ask for a data feed, you
> get an HTML page where JavaScript places content from their local
> data base into an HTML-table. What is going to happen if I cannot
> offer customers like these an application they can use for typing
> configuration information? They aren't stupid, they just aren't used
> to writing text with "computer syntax".)

Yes, it's a problem. Not one Config_Files is trying to solve.

> :> : So what are you suggesting the XML-based API should look like?
> :> It should make no mention of XML, of course :-).
> : 
> : Stating what it isn't doesn't really answer any questions. 
> 
> It should look like an API that is completely unaware of any outside
> file format, and it should be able to cover what is proposed on Stephen's
> page. In particular,
> "12. Data are accessed by a key of type String or Wide_String."
> I'm not sure whether this should say that access is from some level
> in the hierarchy to some item at that level (24.), or whether I go
> to that level using a (path) string key or both in one step.
> Any of this will be fine.

Does my grace-config_files_java.ads meet your needs?

> :  Having a very explicit file format finalized before anyone even
> : decides what the API looks like is kind of silly.
> 
> 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.

Please post specific suggestions for changes to the proposed API.
-- 
-- Stephe