From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a26758eec3c2e1ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-19 14:14:44 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-han1.dfn.de!news-koe1.dfn.de!RRZ.Uni-Koeln.DE!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Use of XML for config files Date: Wed, 19 Jun 2002 21:14:43 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <4519e058.0206130553.3ee195f1@posting.google.com> <3D08CAF0.846AA176@san.rr.com> <3D08E539.343A42BF@san.rr.com> <3D0A2686.785D1BAC@san.rr.com> <3D0F53CC.E3CBB193@san.rr.com> <3D0FAA84.ED827CF5@san.rr.com> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1024521283 29036 134.91.4.34 (19 Jun 2002 21:14:43 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Wed, 19 Jun 2002 21:14:43 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:26440 Date: 2002-06-19T21:14:43+00:00 List-Id: Stephen Leake 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 ... 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