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 11:20:29 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: Tue, 18 Jun 2002 18:20:28 +0000 (UTC) Organization: GMUGHDU Message-ID: 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> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1024424428 12707 134.91.4.34 (18 Jun 2002 18:20:28 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Tue, 18 Jun 2002 18:20:28 +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:26276 Date: 2002-06-18T18:20:28+00:00 List-Id: Darren New wrote: : val := conf.get("Section", "super.subkey", "default value goes here"); Fine except that you make a decision to limit us to no subsections unless you allow "Section.Subsection"? A la section_specification ::= section_name { "." section_name } : I'm : trying to see what XML would be supporting that you can't support easily in : the INI format. (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? :-) Actually I'm fond of something like restricted XPath expressions. They need not necessarily look like XPath expressions, I'm thinking of a 1:1 mapping, if the (hidden) mechanism uses XML. This way we could have a sectioning depth as needed by the application, but it would always look like a dictionary lookup. Unless I want all configuration data for one subsection or one item, for which see below. 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 '.'? How many lines would you have to read for brush.xxx? How do you know that when you have found brush.xxx lines and the pen.xxx lines, there will be no more brush.xxx line after the pen.xxx lines? You whould have to keep track of them all, afaics, in a sorted map? Or use some equivalent mechanis. If I use valid XML configuration data, then by previous validation (if it has taken place), the brush node and only the brush node below the tools node will contain all properties of the brush. You cannot but by discipline require that there be only one brush setting in exactely one tools section, can you? (That is, the mechanics for dealing with conf data would have to check this, which is another programming task for INI files, to some extent mimiccing XML validation; this _could_ be different for XML because you can couple your product with a tailored conf editing component sold to your customer (such things exist :-) See below for hand editing). If conf values are big, will your customers be happy to have to edit overly long lines? Would they be able to do that with Wordpad? And without destructive effects? (I've elsewhere mentioned the problems induced by line breaks.) OTOH, as Stephen mentions on his page, XML hand editing requires knowledge of XML Syntax. But the issue (for me) here is that you can get _any_ non-idiot-proof syntax wrong. I doubt that there is an idiot-proof way of dealing with this problem. (I'm not excluding myself from the set of idiots here, I do use parsers :-) How are the configuration values stored internally? In a hash table indexed by dotted names? This would require repeated "parsing", for example if I wanted to write out anything having to do with brushes, since I have to look for the "tools.brush" prefix. Right? If the values are stored in an tree, wouldn't this effort in effect start building DOM support for INI files? :-) : So what are you suggesting the XML-based API should look like? It should make no mention of XML, of course :-). My idea is that ideally (o.K., whatelse is an idea! :-) it is an option to choose a format and/or provide for functionality to convert between them, if that is possible (for example it is possible in one direction from INI->XML; the opposite might not be easily done because applications might have to be partly rewritten to cope with nested sections.) -- Georg