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-18 14:47:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!netnews.com!xfer02.netnews.com!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3D0FAA84.ED827CF5@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Use of XML for config files References: <4519e058.0206100702.5a4b431a@posting.google.com> <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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 18 Jun 2002 21:47:20 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1024436840 66.75.151.160 (Tue, 18 Jun 2002 14:47:20 PDT) NNTP-Posting-Date: Tue, 18 Jun 2002 14:47:20 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:26311 Date: 2002-06-18T21:47:20+00:00 List-Id: 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. > (I'm guessing that if we go on, you would be demonstrating > that by building special syntax into the keys in an INI file > you could do pretty much anything that can be done with XML? :-) You're arguing a different argument than I'm arguing. > For an example of what cannot easily be done in INI format, > the distinction between values that are in fact > properties of items (like in the brush example) and values > for "stand alone" items (to me) are not really explicit in k=v, unless > the dot has this meaning. But when does a '.' have this meaning? > For example in a.b.c, what meaning does the first dot have > what meaning has the second? Aren't you introducing context > dependent meanings of the symbol '.'? I think you're *still* asking questions instead of answering them. You may be right. Maybe only XML is powerful enough to do what you want. 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. For exmaple, > How are the configuration values stored internally? Such a question is far too premature, considering that you haven't even given the vaguest outline of what you expect your API to look like. If you want some API where the order of keys matters, then you're thinking something completely different than I am. > : 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 is an option to choose a format and/or provide > for functionality to convert between them, if that is possible Again, premature. Having a very explicit file format finalized before anyone even decides what the API looks like is kind of silly. That said, see my other post following up the API proposed by Mr Leake. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug.