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 04:31:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!newsswitch.lcs.mit.edu!snoopy.risq.qc.ca!newsfeed.belnet.be!news.belnet.be!newsfeed.vmunix.org!newsfeed.hanau.net!news-fra1.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 11:31:14 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <3D0769F7.68F5BD9C@san.rr.com> <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 1024486274 22850 134.91.4.34 (19 Jun 2002 11:31:14 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Wed, 19 Jun 2002 11:31:14 +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:26370 Date: 2002-06-19T11:31:14+00:00 List-Id: Darren New 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! 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") 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. 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. 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, 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".) :> : 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. : 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? But I admit that this is likely to have been what I have been focussing on during this discussion. Which has been helpful in many respects. -- Georg