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-14 10:22:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!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: <3D0A2686.785D1BAC@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: <3CFC5DB2.A21DCF61@cs.tu-berlin.de> <4519e058.0206041129.5b250124@posting.google.com> <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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 17:22:51 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1024075371 66.75.151.160 (Fri, 14 Jun 2002 10:22:51 PDT) NNTP-Posting-Date: Fri, 14 Jun 2002 10:22:51 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:25960 Date: 2002-06-14T17:22:51+00:00 List-Id: Georg Bauhaus wrote: > > Darren New wrote: > : the order of tags in XML is quite explicitly important. > > Unless the DTD says it doesn't matter (in repeated alternatives). It still matters.

First

Second

First

Contrast with [Colors] red=0xFF0000 blue=0x0000FF [Colors] blue=0x0000FF red=0xFF0000 > : Difficult to do if you use XML, because XML has a particular semantics for > : comments. > > None that I know of. You can put pretty much anything in a comment other > than --. That's the syntax of comments. If you're saying that comments attach to whatever object they're nested in, then that's different from comments attach to whatever comes next. Note that the goal would be to preserve comments correctly (for some value of "correct") in the event that the program edits the config file, inserting deleteing and merging items. > : "the comment always attaches to > : whatever non-comment object comes next." > > Why shouldn't that be possible with XML? 1) It would be, but you said comments should attach to their container. 2) Comments can be followed by more comments. Do comments attach to comments? 3) What about comments at the end of a structure? > This isn't what I would want it to do, it should (if necessary) help > overcome the limitations of sectioned key-value settings. Right. You're agreeing with me. What do you want it to do? Don't tell me "it eliminates the problems with your format." Tell me what it does *positively*. What problems does it eliminate and how, that makes it worth the extra syntax? > : Perhaps offering an idea of the API you're envisioning > : would help it move forward. > > Suppose an INI-like API would cover sections and key-value settings > in a section, using any syntax. Then in your example you might have > > [tools] > brush=round airbrush green > ... > > (Maybe you would do it differently?) > > This leaves some room for parsing, in that you would have to specify > 1st is shape, 2nd is type, 3rd is color. or brush.type=airbrush brush.shape=round brush.color=green > whereas > > > ... > > > makes this unnecessary. Much like named parameters in Ada. OK. So we add a little more to the ini format. We still don't get into matched-tags hell etc. > In addition, as you can see in the example, > I am thinking of an application which (perhaps unlike > other applications) might profit from tags that do not just > mimic INI-style "key" and "value". This makes the configuration > look like application specific, but why not? The software for > fiddling with the configuration data doesn't have to be, except > for the necessary parameterizations of subprograms, > say (for example if you want the attribute list of the current > tool, which is a String = Name_Of(Brush)). Maybe I'm not seeing any big difference between "XML parser" and "Config file API" here. If someone wants a config file that complex, why not just use one of the existing XML parsers? -- 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.