* Re: Use of XML for config files
@ 2002-06-05 10:02 Grein, Christoph
2002-06-09 22:13 ` Stephen Leake
0 siblings, 1 reply; 83+ messages in thread
From: Grein, Christoph @ 2002-06-05 10:02 UTC (permalink / raw)
> I would prefer nested configuraton sections, and simplify the notation
> for key/value pairs:
>
> <configuration>
> <section name="Section1">
> <section name="SubSectionA">
> <key name="Key1">Value1</key>
> <key name="Key2">Value2</key>
> </section>
> <key name="KeyX">ValueX</key>
> </section>
> </configuration>
I would also prefer this syntax. It's much shorter and thus easier to read.
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 10:02 Use of XML for config files Grein, Christoph @ 2002-06-09 22:13 ` Stephen Leake 2002-06-10 1:42 ` Darren New 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-09 22:13 UTC (permalink / raw) "Grein, Christoph" <christoph.grein@eurocopter.com> writes: > > I would prefer nested configuraton sections, and simplify the notation > > for key/value pairs: > > > > <configuration> > > <section name="Section1"> > > <section name="SubSectionA"> > > <key name="Key1">Value1</key> > > <key name="Key2">Value2</key> > > </section> > > <key name="KeyX">ValueX</key> > > </section> > > </configuration> > > I would also prefer this syntax. It's much shorter and thus easier to read. The draft implementation I'm working on uses this instead: <config> <Section1> <SubSectionA> <Key1>Value1</Key1> <Key2>Value2</Key2> </SubSectionA> <KeyX>ValueX</KeyX> </Section1> </config> This is the style generated by the Glib.XML package. It's even shorter :). I am an XML beginner. I gather the <key name="foo">value</key> style is more amenable to definition via DTD or schema? What other virtues does it have? I'll look into modifying the Glib.XML package to generate this style, as draft implementation 2. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-09 22:13 ` Stephen Leake @ 2002-06-10 1:42 ` Darren New 2002-06-10 12:46 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-10 1:42 UTC (permalink / raw) Stephen Leake wrote: > I am an XML beginner. I gather the <key name="foo">value</key> style is > more amenable to definition via DTD or schema? What other virtues does > it have? On the other hand, it says less. So you cannot, for example, say "the foo package must configure a bar and a baz." You could do that if the format was <foo> <bar>My stuff</bar> <baz>Your stuff</baz> </foo> But not if it was <package name="foo"> <key name="bar">My stuff</key> <key name="baz">Your stuff</key> </package> -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 1:42 ` Darren New @ 2002-06-10 12:46 ` Stephen Leake 2002-06-10 15:52 ` Darren New 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-10 12:46 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > I am an XML beginner. I gather the <key name="foo">value</key> style is > > more amenable to definition via DTD or schema? What other virtues does > > it have? > > On the other hand, it says less. So you cannot, for example, say "the foo > package must configure a bar and a baz." You could do that if the format was > <foo> > <bar>My stuff</bar> > <baz>Your stuff</baz> > </foo> Do you mean "in the DTD, you cannot say .."? Are you implying that each app should have its own DTD? I guess that makes sense. > But not if it was > <package name="foo"> > <key name="bar">My stuff</key> > <key name="baz">Your stuff</key> > </package> In this case, I'm guessing that we could have one DTD for all config files. But you are right, it would not say much, so maybe that is not useful. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 12:46 ` Stephen Leake @ 2002-06-10 15:52 ` Darren New 0 siblings, 0 replies; 83+ messages in thread From: Darren New @ 2002-06-10 15:52 UTC (permalink / raw) Stephen Leake wrote: > > Darren New <dnew@san.rr.com> writes: > > > Stephen Leake wrote: > > > I am an XML beginner. I gather the <key name="foo">value</key> style is > > > more amenable to definition via DTD or schema? What other virtues does > > > it have? > > > > On the other hand, it says less. So you cannot, for example, say "the foo > > package must configure a bar and a baz." You could do that if the format was > > <foo> > > <bar>My stuff</bar> > > <baz>Your stuff</baz> > > </foo> > > Do you mean "in the DTD, you cannot say .."? Are you implying that > each app should have its own DTD? I guess that makes sense. I'm saying that if each app has its own DTD, that DTD can say that a foo includes a bar and a baz. If the style of <key name="something">value</key> is used, then the DTD for all config files will be the same. In the former case, you get extra checking, extra specification, and more readable config files, at the expense of having different DTDs for each config file. In the latter case, you have the advantage of having a fixed number of keys to look at, but the application has more work to do to check the correctness. In the former case, you could also have things like <recent_files> <file> My Work.doc </file> <file> Nancy.jpg </file> <file> http://www.adapower.com </file> </recent_files> Altho you could probably do that with the <key> syntax, it wouldn't be nearly as clear, I expect. INI files, of course, use recent.1, recent.2, recent.3 and so on. > In this case, I'm guessing that we could have one DTD for all config > files. But you are right, it would not say much, so maybe that is not > useful. Right. It's basically the same as a INI file, semantically speaking. That is, all the checking that everything needed is there the right number of times is left up to the application, rather than the config file definition. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files @ 2002-06-05 8:25 Grein, Christoph 2002-06-05 8:39 ` Volkert Barr 2002-06-05 9:31 ` Manuel Collado 0 siblings, 2 replies; 83+ messages in thread From: Grein, Christoph @ 2002-06-05 8:25 UTC (permalink / raw) From: Volkert Barr <barr@cs.tu-berlin.de> > > Where is this grammar? > > > I hope Stephan Leake will add it to his "Config-Proposal Page"! Where is this page? I've just entered this thread (back from holidays). > > > > > XML-like Configuration: > > > > > > <configuration> > > > <config_item name= "Config_Item1" > > > > <Key> Key </Key> > > > <value> Value </value> > > Can this be repeated? There might be more than one key for a config_item.> > Sure ! Remeber this just an example and not a syntax definition!! > > > > <config_item name = "Config_Item2" > > > > <entry> > > What's the use of <entry>? > A Config_Item can have a list of Entries which are > Key/Value Pairs! Thats typical XML Style! I know XML... Why <entry> inside an inner <config_item name = "Config_Item2" > and not inside an outer <config_item name= "Config_Item1" >. This is inconsistent and looks superfluous. And by the way: XML requires an end tag for the inner config_item which you have forgotten in your example. > <entry> > <key> Name </key> > <value> Grein </value> > </entry> > <entry> > <key> Vorname </key> > <value> Christoph</value> > </entry> So your proposal looks like (???) <configuration> <config_item name="Config_Item1"> <entry> <Key> Key </Key> <value> Value </value> </entry> <config_item name="Config_Item2"> <entry> <key> Key </key> <value> Value </value> </entry> </config_item> </config_item> </configuration> ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 8:25 Grein, Christoph @ 2002-06-05 8:39 ` Volkert Barr 2002-06-05 9:31 ` Manuel Collado 1 sibling, 0 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-05 8:39 UTC (permalink / raw) "Grein, Christoph" wrote: > > From: Volkert Barr <barr@cs.tu-berlin.de> > > > Where is this grammar? > > > > I hope Stephan Leake will add it to his "Config-Proposal Page"! > > Where is this page? I've just entered this thread (back from holidays). http://users.erols.com/leakstan/Stephe/Ada/config_files.html > > > > > > XML-like Configuration: > > > > > > > > <configuration> > > > > <config_item name= "Config_Item1" > > > > > <Key> Key </Key> > > > > <value> Value </value> > > > Can this be repeated? There might be more than one key for a config_item.> > > Sure ! Remeber this just an example and not a syntax definition!! > > > > > > <config_item name = "Config_Item2" > > > > > <entry> > > > What's the use of <entry>? > > A Config_Item can have a list of Entries which are > > Key/Value Pairs! Thats typical XML Style! > > I know XML... Why <entry> inside an inner <config_item name = "Config_Item2" > > and not inside an outer <config_item name= "Config_Item1" >. This is > inconsistent and looks superfluous. ok! The name Config_Item is not a good one! Should be called "Section" and entry sould be called "item" (as in the model i just send you!) > And by the way: XML requires an end tag for the inner config_item which you have > forgotten in your example. Yep! I know XML! It was just a mistake! <configuration> <section name="Bla"> <item> <key> Key </key> <value> Value </value> </item> <section name="InnerBla"> <item> <key> Key </key> <value> Value </value> </item> <item> <key> Key </key> <value> Value </value> </item> </section> </section> </configuration> ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 8:25 Grein, Christoph 2002-06-05 8:39 ` Volkert Barr @ 2002-06-05 9:31 ` Manuel Collado 2002-06-05 10:01 ` Volkert Barr 1 sibling, 1 reply; 83+ messages in thread From: Manuel Collado @ 2002-06-05 9:31 UTC (permalink / raw) "Grein, Christoph" wrote: > ... > So your proposal looks like (???) > > <configuration> > <config_item name="Config_Item1"> > <entry> > <Key> Key </Key> > <value> Value </value> > </entry> > <config_item name="Config_Item2"> > <entry> > <key> Key </key> > <value> Value </value> > </entry> > </config_item> > </config_item> > </configuration> I would prefer nested configuraton sections, and simplify the notation for key/value pairs: <configuration> <section name="Section1"> <section name="SubSectionA"> <key name="Key1">Value1</key> <key name="Key2">Value2</key> </section> <key name="KeyX">ValueX</key> </section> </configuration> This is roughly equivalent to the convention notation: [Section1.SubSectionA] Key1=Value1 Key2=Value2 [Section1] KayX=ValueX -- To reply by e-mail, please remove the extra dot in the given address: m.collado -> mcollado ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 9:31 ` Manuel Collado @ 2002-06-05 10:01 ` Volkert Barr 0 siblings, 0 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-05 10:01 UTC (permalink / raw) > I would prefer nested configuraton sections, and simplify the notation > for key/value pairs: > <configuration> > <section name="Section1"> > <section name="SubSectionA"> > <key name="Key1">Value1</key> > <key name="Key2">Value2</key> > </section> > <key name="KeyX">ValueX</key> > </section> > </configuration> Yes, looks much cleaner! Noted! Thanks, Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files @ 2002-06-05 7:33 Grein, Christoph 2002-06-05 7:59 ` Volkert Barr 0 siblings, 1 reply; 83+ messages in thread From: Grein, Christoph @ 2002-06-05 7:33 UTC (permalink / raw) From: Volkert Barr <barr@cs.tu-berlin.de> > I have set up a first small datamodel for hierarchical configuration > data (nested Config_Items containing lists of (Key,Value)-Tupels) > and defined a BNF-Grammar for text (file) representation of this > data. Where is this grammar? > I hope Stephan Leake will add it to his "Config-Proposal Page"! > > The grammes defines the following style: > > -- > -- Comment Block > -- > Config_Item1.Key := Value > > -- Comment > Config_Item1.Inner_Config_Item2.Key := Value > > > The same can be done in XML, but the next you need is > an "XML Editor" ;-) (That is one reason, why there is so > much Business (and money) around XML.) > > XML-like Configuration: > > <configuration> > <config_item name= "Config_Item1" > > <Key> Key </Key> > <value> Value </value> Can this be repeated? There might be more than one key for a config_item. > <config_item name = "Config_Item2" > > <entry> What's the use of <entry>? > <key> Key </key> > <value> Value </value> > </entry> </config_item> is missing here. > </config_item> > </configuration> ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 7:33 Grein, Christoph @ 2002-06-05 7:59 ` Volkert Barr 0 siblings, 0 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-05 7:59 UTC (permalink / raw) > Where is this grammar? > > I hope Stephan Leake will add it to his "Config-Proposal Page"! > > XML-like Configuration: > > > > <configuration> > > <config_item name= "Config_Item1" > > > <Key> Key </Key> > > <value> Value </value> > Can this be repeated? There might be more than one key for a config_item.> Sure ! Remeber this just an example and not a syntax definition!! > > <config_item name = "Config_Item2" > > > <entry> > What's the use of <entry>? A Config_Item can have a list of Entries which are Key/Value Pairs! Thats typical XML Style! <entry> <key> Name </key> <value> Grein </value> </entry> <entry> <key> Vorname </key> <value> Christoph</value> </entry> Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Use of XML for config files @ 2002-06-03 11:48 Mike and Lynn Card 2002-06-03 17:42 ` Pascal Obry 2002-06-04 6:26 ` Volkert Barr 0 siblings, 2 replies; 83+ messages in thread From: Mike and Lynn Card @ 2002-06-03 11:48 UTC (permalink / raw) Hello CLA- I thought I would mention that some of our programs at Lockheed-Martin have begun using XML for configuration files. It really is handy because you don't have to write your own token-paring code, and I would expect it to eventually become standard practice. I used XML recently on a project to store some static configuration data and read it in and turned it into Ada objects using the SAX facility in XMLAda. This was a great technique that saved me a lot of time. Just my $0.02, YMMV. - Mike ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-03 11:48 Mike and Lynn Card @ 2002-06-03 17:42 ` Pascal Obry 2002-06-04 6:26 ` Volkert Barr 1 sibling, 0 replies; 83+ messages in thread From: Pascal Obry @ 2002-06-03 17:42 UTC (permalink / raw) Mike and Lynn Card <thehouseofcards@remove.this.part.mac.com> writes: > Hello CLA- > > I thought I would mention that some of our programs at Lockheed-Martin > have begun using XML for configuration files. It really is handy because > you don't have to write your own token-paring code, and I would expect > it to eventually become standard practice. I second that and think that a configuration file, designed today, not based on XML would be a mistake. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-03 11:48 Mike and Lynn Card 2002-06-03 17:42 ` Pascal Obry @ 2002-06-04 6:26 ` Volkert Barr 2002-06-04 12:47 ` SteveD ` (2 more replies) 1 sibling, 3 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-04 6:26 UTC (permalink / raw) Mike and Lynn Card wrote: > > Hello CLA- > > I thought I would mention that some of our programs at Lockheed-Martin > have begun using XML for configuration files. It really is handy because > you don't have to write your own token-paring code, and I would expect > it to eventually become standard practice. > I used XML recently on a project to store some static configuration data > and read it in and turned it into Ada objects using the SAX facility in > XMLAda. This was a great technique that saved me a lot of time. Yes XML can help here, but the most projects i have seen, XML was a complete overkill! Don't forget, that a syntax definition the XML files is necessary and parsing/navigation/errorhandling is still your problem! I believe, a simple Package/Key/Value Style works well for most problems. And today, XMLAda based on the GNAT Spitbol package and is not compiler independent! But compiler independence should be an requirement for the Configuration Packages! If there is a consensus that XML is needed, the Spitbowl Package must be ported! Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 6:26 ` Volkert Barr @ 2002-06-04 12:47 ` SteveD 2002-06-04 13:51 ` Volkert Barr 2002-06-04 19:29 ` Ted Dennison 2002-06-09 21:52 ` Stephen Leake 2 siblings, 1 reply; 83+ messages in thread From: SteveD @ 2002-06-04 12:47 UTC (permalink / raw) "Volkert Barr" <barr@cs.tu-berlin.de> wrote in message news:3CFC5DB2.A21DCF61@cs.tu-berlin.de... [snip] > And today, XMLAda based on the GNAT Spitbol package and is not > compiler independent! But compiler independence should be an requirement for > the Configuration Packages! If there is a consensus that XML is needed, > the Spitbowl Package must be ported! Done. I took the GNAT.Spitbol package, extracted the subset that XMLAda requires, and fixed up the result to get rid of Unrestricted_Access, 'Img and Gnat.Io. I submitted this to the maintainer at least a month ago. I have compiled an run the result using ObjectAda 7.2. SteveD > > Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 12:47 ` SteveD @ 2002-06-04 13:51 ` Volkert Barr 0 siblings, 0 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-04 13:51 UTC (permalink / raw) SteveD wrote: > > "Volkert Barr" <barr@cs.tu-berlin.de> wrote in message > news:3CFC5DB2.A21DCF61@cs.tu-berlin.de... > [snip] > > And today, XMLAda based on the GNAT Spitbol package and is not > > compiler independent! But compiler independence should be an requirement > for > > the Configuration Packages! If there is a consensus that XML is needed, > > the Spitbowl Package must be ported! > > Done. [...] Good to know! ;-) Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 6:26 ` Volkert Barr 2002-06-04 12:47 ` SteveD @ 2002-06-04 19:29 ` Ted Dennison 2002-06-05 7:18 ` Volkert Barr ` (2 more replies) 2002-06-09 21:52 ` Stephen Leake 2 siblings, 3 replies; 83+ messages in thread From: Ted Dennison @ 2002-06-04 19:29 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> wrote in message news:<3CFC5DB2.A21DCF61@cs.tu-berlin.de>... > the Configuration Packages! If there is a consensus that XML is needed, > the Spitbowl Package must be ported! I don't think this would be nessecary or a good idea. Making our own Configuration XML parser is not out of the question. Parsing any XML language that anyone could ever come up with is a very different task than parsing a specific XML language. Making an XML parser customised to the configuration XML language (whatever that would end up being) may be more work than using ACT's XML reader, but it wouldn't be an undoable effort. We really only need to make the package *spec*s portable Ada. It would be nice to have a portable reference implementation too, but its not an absolute nessecity to have one, as long as its *possible* to make one. However, I agree with you that its probably more work than the task requires. I think it would be silly to use XML, unless we are getting something out of it that we can't easily get out of other grammars. PR is *not* a sufficient answer. :-) What that means is that if we were to use XML, we should support both user-defined configuration item attributes and some kind of object nesting (configuration items defined within other configuration items). I haven't really heard anyone seriously arguing the usefulness of this stuff. If we are to stick with simple attribute-value pairs, then XML would be major overkill. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 19:29 ` Ted Dennison @ 2002-06-05 7:18 ` Volkert Barr 2002-06-05 10:24 ` Georg Bauhaus 2002-06-05 14:41 ` Robert C. Leif 2002-06-09 22:00 ` Stephen Leake 2002-06-10 14:45 ` Georg Bauhaus 2 siblings, 2 replies; 83+ messages in thread From: Volkert Barr @ 2002-06-05 7:18 UTC (permalink / raw) > What that means is that if we were to use XML, we should support both > user-defined configuration item attributes and some kind of object > nesting (configuration items defined within other configuration > items). I haven't really heard anyone seriously arguing the usefulness > of this stuff. > > If we are to stick with simple attribute-value pairs, then XML would > be major overkill. I have set up a first small datamodel for hierarchical configuration data (nested Config_Items containing lists of (Key,Value)-Tupels) and defined a BNF-Grammar for text (file) representation of this data. I hope Stephan Leake will add it to his "Config-Proposal Page"! The grammes defines the following style: -- -- Comment Block -- Config_Item1.Key := Value -- Comment Config_Item1.Inner_Config_Item2.Key := Value The same can be done in XML, but the next you need is an "XML Editor" ;-) (That is one reason, why there is so much Business (and money) around XML.) XML-like Configuration: <configuration> <config_item name= "Config_Item1" > <Key> Key </Key> <value> Value </value> <config_item name = "Config_Item2" > <entry> <key> Key </key> <value> Value </value> </entry> </config_item> </configuration> Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 7:18 ` Volkert Barr @ 2002-06-05 10:24 ` Georg Bauhaus 2002-06-05 11:35 ` Preben Randhol 2002-06-05 14:41 ` Robert C. Leif 1 sibling, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-05 10:24 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> wrote: : : <configuration> ... : </configuration> I think key-value pairs are ideal for attributes. A quick hack: <!DOCTYPE configuration [ <!ELEMENT configuration (group*)> <!ELEMENT group (item+)> <!ATTLIST group name NMTOKEN #REQUIRED > <!ELEMENT item (setting*, group*)> <!ATTLIST item id ID #IMPLIED > <!ELEMENT setting EMPTY> <!ATTLIST setting key NMTOKEN #REQUIRED value CDATA #REQUIRED > ]> <configuration> <group name="directories"> <item id="locations"> <setting key="top" value="//hurz/foo/bar"/> <setting key="temp" value="$system.temp"/> <group name="access-control"> <item> <setting key="master" value="all"/> <setting key="scratch-space" value="see"/> </item> </group> </item> </group> </configuration> ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 10:24 ` Georg Bauhaus @ 2002-06-05 11:35 ` Preben Randhol 2002-06-05 14:52 ` Georg Bauhaus 2002-06-06 6:48 ` Volkert Barr 0 siblings, 2 replies; 83+ messages in thread From: Preben Randhol @ 2002-06-05 11:35 UTC (permalink / raw) On Wed, 5 Jun 2002 10:24:12 +0000 (UTC), Georg Bauhaus wrote: > <item> > <setting key="master" value="all"/> > <setting key="scratch-space" value="see"/> > </item> Why do you use meta-data through arguments. Why not: <setting> <key>master</key> <value>all</value> </setting> ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 11:35 ` Preben Randhol @ 2002-06-05 14:52 ` Georg Bauhaus 2002-06-05 15:22 ` Preben Randhol 2002-06-05 19:11 ` Darren New 2002-06-06 6:48 ` Volkert Barr 1 sibling, 2 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-05 14:52 UTC (permalink / raw) Preben Randhol <randhol+abuse@pvv.org> wrote: : On Wed, 5 Jun 2002 10:24:12 +0000 (UTC), Georg Bauhaus wrote: :> <setting key="master" value="all"/> : : Why do you use meta-data through arguments. Why not: meta-data? arguments? I'm not sure I understand. : : <setting> : <key>master</key> : <value>all</value> : </setting> 1) This loses type information on allowable key data ("master" in this case), and as the discussion has shown, it might be desirable to restrict keys to a few sensible characters, that is NMTOKEN. 2) The idea is to use attributes as properties. If you have foo := bla some value blub this maps nicely to <setting key="foo" value="bla some value blub"/> This is what attributes are for, there is one thing (a setting, if someone finds a better word, that would be nice, I'm not English) which is a key-value mapping. It is concise, and it circumvents the necessity to add key- and value-children to the content model of setting: If you think of this as nodes in the grove, there is only one node concerning one adjustable thing in an application. The node has the setting for one application-thing keyed "master" in this case, using attributes present in this node. Otherwise you would have three element nodes in a subtree, where the top node (setting) isn't used, except as a container for two other child nodes, key and value, which have the key name in the first child and the value in the second child. The element content of the second child is to be used as the value of the setting keyed by the element content of the first child. I find the attribute way a lot more pleasant. -- Georg --- ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 14:52 ` Georg Bauhaus @ 2002-06-05 15:22 ` Preben Randhol 2002-06-05 19:11 ` Darren New 1 sibling, 0 replies; 83+ messages in thread From: Preben Randhol @ 2002-06-05 15:22 UTC (permalink / raw) On Wed, 5 Jun 2002 14:52:28 +0000 (UTC), Georg Bauhaus wrote: > Preben Randhol <randhol+abuse@pvv.org> wrote: >: On Wed, 5 Jun 2002 10:24:12 +0000 (UTC), Georg Bauhaus wrote: >:> <setting key="master" value="all"/> >: >: Why do you use meta-data through arguments. Why not: > meta-data? > arguments? I'm not sure I understand. sorry attributes I meant. I was reading http://www.w3schools.com/xml/xml_attributes.asp, but I also found: http://www.xmleverywhere.com/newsletters/20000525.htm which have a different view. This page has a lot of links on this: http://www.oasis-open.org/cover/elementsAndAttrs.html Preben ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 14:52 ` Georg Bauhaus 2002-06-05 15:22 ` Preben Randhol @ 2002-06-05 19:11 ` Darren New 2002-06-06 13:38 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-05 19:11 UTC (permalink / raw) Georg Bauhaus wrote: > > Preben Randhol <randhol+abuse@pvv.org> wrote: > : On Wed, 5 Jun 2002 10:24:12 +0000 (UTC), Georg Bauhaus wrote: > :> <setting key="master" value="all"/> > : > : Why do you use meta-data through arguments. Why not: > meta-data? > arguments? I'm not sure I understand. > : > : <setting> > : <key>master</key> > : <value>all</value> > : </setting> > > 1) This loses type information on allowable key data ("master" > in this case), and as the discussion has shown, it might be > desirable to restrict keys to a few sensible characters, that > is NMTOKEN. > > 2) The idea is to use attributes as properties. If you have > > foo := bla some value blub > > this maps nicely to > > <setting key="foo" value="bla some value blub"/> Actually, it maps nicely to <setting key="foo"> bla some value blub </setting> which would allow pretty much arbitrary text in the value with minimal escapage necessary. > This is what attributes are for, Well, er, not really, but OK. :-) > I find the attribute way a lot more pleasant. Until you get values that are complex, multiple lines, long, contain weird characters, etc. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 19:11 ` Darren New @ 2002-06-06 13:38 ` Georg Bauhaus 2002-06-06 15:06 ` Darren New 0 siblings, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-06 13:38 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : Actually, it maps nicely to : <setting key="foo"> bla some value blub </setting> : which would allow pretty much arbitrary text in the value with minimal : escapage necessary. True. Though line break are not a problem, they will just go away due to normalization (if that is a problem, then o.K.) (I'm saying this because I see many people thinking that attribute values are very restricted, I find this misleading.) :> This is what attributes are for, : : Well, er, not really, but OK. :-) o.K, that was a bit loadmothed (by me), but it depends on the definition of attributes. SGML/XML attributes aren't required to be what some people attribute to attributes*) (where some seem not to be talking of SGML/XML-attributes but about some general notion of attributes.) That is, (see Goldfarb/Prescod Sec 54.6) it is up to the designer of the document type to decide what to put in attributes and what to put in element content. They suggest two non-exhaustive guiding criteria: - attributes cannot contain elements (as you said) - attributes cannot have occurence indicators Therefore, if values for keys - do/don't contain elements..., - occur exactly once..., - can e.g. have but "on" or "off" as values,... (so <!ATTLIST feature value (on | off) on>) Chose something that meets your purpose. E.g. when working in 3D-space I can't see anything too wrong with an "attribute based" matrix, since its structure is fixed and will stay so: <!ELEMENT eu3D-trans (row, row, row)> ... <eu3D-trans> <row x="3.2" y="14.2" z="4.1"> ... </eu3D-trans> However, if you insist on a meta-information restriction for attributes, say, can you handle this case but by the introduction of some more element types, which, in XML, might become rather noisy? (Whether the row is the best fit for a eu3D-trans part I don't know) *) And never mind whether or not some (probably young and publishing? :-) computer scientists have superimposed a meta-information model on XML, there is no need to restrict the capabilities of DTDs just because some meta-information orientation can be mapped to XML attributes! :-) -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-06 13:38 ` Georg Bauhaus @ 2002-06-06 15:06 ` Darren New 2002-06-07 11:28 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-06 15:06 UTC (permalink / raw) Georg Bauhaus wrote: > That is, (see Goldfarb/Prescod Sec 54.6) > it is up to the designer of the document type to decide what > to put in attributes and what to put in element content. They > suggest two non-exhaustive guiding criteria: Well, what you say is true and good. I was just pointing out that in theory, the *content* of a document is everything outside the < > and everything inside the < > is metadata. That is, you should get a comprehensible piece of text simply by deleting all the tags. Of course, once you're talking about things like configuration data and other such database-like stuff, rather than a readable document containing prose, you're no longer talking about documents, so there is a bit more flexibility. I think <element key="hello"> value is textual </element> makes more sense and will likely require less quoting. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-06 15:06 ` Darren New @ 2002-06-07 11:28 ` Georg Bauhaus 2002-06-07 17:10 ` Darren New 0 siblings, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-07 11:28 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : database-like stuff, rather than a readable document containing : prose, you're no longer talking about documents, so there is a bit more : flexibility. Yes and no, because "document" is a defined term in SGML/XML, and this is what I was thinking of in this XML discussion. Here is the (short) SGML definition: 4.96 document: A collection of information that is processed as a unit. A document is classified as being af a particular document type. NOTE--In this International Standard, the term almost invariably means (without loss of accuracy) an SGML document. XML 1.0: By construction, XML documents are conforming SGML documents. [Definition: A data object is an XML document if it is well-formed, as defined in this specification. A well-formed XML document may in addition be valid if it meets certain further constraints.] -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-07 11:28 ` Georg Bauhaus @ 2002-06-07 17:10 ` Darren New 0 siblings, 0 replies; 83+ messages in thread From: Darren New @ 2002-06-07 17:10 UTC (permalink / raw) Georg Bauhaus wrote: > > Darren New <dnew@san.rr.com> wrote: > : database-like stuff, rather than a readable document containing > : prose, you're no longer talking about documents, so there is a bit more > : flexibility. > > Yes and no, because "document" is a defined term in SGML/XML, > and this is what I was thinking of in this XML discussion. Well, yes, I was talking about "document" like normal people use it, not as defined in a standard about text processing. :-) My point was, once you're not talking about something that humans would consider "readable prose", then the distinction between "character data" and "attribute values" (which are also strings of characters) becomes much less important. If what you're writing is a DTD for prose (like, say, manual pages, books, etc), rather than "data" (like a metainformation database or config files), then understanding the distinction between PCDATA and attribute values is worthwhile. Otherwise, it's whatever looks nice and is convenient. Nuff said. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-05 11:35 ` Preben Randhol 2002-06-05 14:52 ` Georg Bauhaus @ 2002-06-06 6:48 ` Volkert Barr 2002-06-06 13:27 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Volkert Barr @ 2002-06-06 6:48 UTC (permalink / raw) Preben Randhol wrote: > > On Wed, 5 Jun 2002 10:24:12 +0000 (UTC), Georg Bauhaus wrote: > > <item> > > <setting key="master" value="all"/> > > <setting key="scratch-space" value="see"/> > > </item> > > Why do you use meta-data through arguments. Why not: > > <setting> > <key>master</key> > <value>all</value> > </setting> Manuello suggested this style <configuration> <section name="Section1"> <section name="SubSectionA"> <key name="Key1">Value1</key> <key name="Key2">Value2</key> </section> <key name="KeyX">ValueX</key> </section> </configuration> If we use XML for config-file data representation, i would like to see this style. Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-06 6:48 ` Volkert Barr @ 2002-06-06 13:27 ` Georg Bauhaus 0 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-06 13:27 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> wrote: : : <configuration> : <section name="Section1"> : <section name="SubSectionA"> looks fine, however, I'd definitely put nesting information (section, subsection, ...; or recursive nesting) in the grammar, viz DTD, not in data content of attribute "name". The name should be what is suggests it is: the (sub*)section's name :-) : <key name="Key1">Value1</key> : <key name="Key2">Value2</key> : </section> : <key name="KeyX">ValueX</key> : </section> : </configuration> : ^ permalink raw reply [flat|nested] 83+ messages in thread
* RE: Use of XML for config files 2002-06-05 7:18 ` Volkert Barr 2002-06-05 10:24 ` Georg Bauhaus @ 2002-06-05 14:41 ` Robert C. Leif 1 sibling, 0 replies; 83+ messages in thread From: Robert C. Leif @ 2002-06-05 14:41 UTC (permalink / raw) From: Bob Leif To: Volkert Barr et al. Following standard Ada practice, one should declare all the types for the elements and, if one uses them, attributes. The best way to do this is to create both an XML schema and an Ada package specification. The data types and ranges of the two documents should be identical. The combination of validating the schema and compiling the specification is equivalent to man whose hazard analysis leads him to wear both a belt and suspenders (I believe braces in the UK). The first step is to decide on the data types. For the convenience of all this can be done in Ada. The second step is to determine if they should be expressed as XML elements or attributes. XMLSpy or similar tool can be employed to both create the schema and generate a preliminary XML document. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Volkert Barr Sent: Wednesday, June 05, 2002 12:19 AM To: comp.lang.ada@ada.eu.org Subject: Re: Use of XML for config files > What that means is that if we were to use XML, we should support both > user-defined configuration item attributes and some kind of object > nesting (configuration items defined within other configuration > items). I haven't really heard anyone seriously arguing the usefulness > of this stuff. > > If we are to stick with simple attribute-value pairs, then XML would > be major overkill. I have set up a first small datamodel for hierarchical configuration data (nested Config_Items containing lists of (Key,Value)-Tupels) and defined a BNF-Grammar for text (file) representation of this data. I hope Stephan Leake will add it to his "Config-Proposal Page"! The grammes defines the following style: -- -- Comment Block -- Config_Item1.Key := Value -- Comment Config_Item1.Inner_Config_Item2.Key := Value The same can be done in XML, but the next you need is an "XML Editor" ;-) (That is one reason, why there is so much Business (and money) around XML.) XML-like Configuration: <configuration> <config_item name= "Config_Item1" > <Key> Key </Key> <value> Value </value> <config_item name = "Config_Item2" > <entry> <key> Key </key> <value> Value </value> </entry> </config_item> </configuration> Volkert ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 19:29 ` Ted Dennison 2002-06-05 7:18 ` Volkert Barr @ 2002-06-09 22:00 ` Stephen Leake 2002-06-10 15:03 ` Ted Dennison 2002-06-10 14:45 ` Georg Bauhaus 2 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-09 22:00 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Volkert Barr <barr@cs.tu-berlin.de> wrote in message > news:<3CFC5DB2.A21DCF61@cs.tu-berlin.de>... > > > the Configuration Packages! If there is a consensus that XML is needed, > > the Spitbowl Package must be ported! > > I don't think this would be nessecary or a good idea. Making our own > Configuration XML parser is not out of the question. Parsing any XML > language that anyone could ever come up with is a very different task > than parsing a specific XML language. Making an XML parser customised > to the configuration XML language (whatever that would end up being) > may be more work than using ACT's XML reader, but it wouldn't be an > undoable effort. Yes. > We really only need to make the package *spec*s portable Ada. It > would be nice to have a portable reference implementation too, but > its not an absolute nessecity to have one, as long as its *possible* > to make one. Exactly. > However, I agree with you that its probably more work than the task > requires. I think it would be silly to use XML, unless we are > getting something out of it that we can't easily get out of other > grammars. PR is *not* a sufficient answer. :-) Yes. However, I think the potential for an application to "grow" the config file beyond the Config_File API, and use a "full" XML parser instead, is a Good Thing. Clients with installed config files would not need to change them when the app is upgraded. > What that means is that if we were to use XML, we should support > both user-defined configuration item attributes Just because XML supports this, doesn't mean the Config_File API should. We're looking for a simple subset. If the app decides it needs these, it can go to a full XML parser. > and some kind of object nesting (configuration items defined within > other configuration items). Actually, the "multiple levels" is precisely the same as nested objects. That is: foo.bar.item_1 foo.bar.item_2 foo.figs.item_1 is the same as: object foo object bar item_1 item_2 end object object figs item_1 end object end object Hope that's clear :). > I haven't really heard anyone seriously arguing the usefulness of > this stuff. We all have :). > If we are to stick with simple attribute-value pairs, then XML would > be major overkill. In what way? I have a very small package that parses the subset of XML that I need to meet the Config_File spec (Glib.XML - 671 lines in the body). What's wrong with that? -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-09 22:00 ` Stephen Leake @ 2002-06-10 15:03 ` Ted Dennison 2002-06-10 18:12 ` Stephen Leake 2002-06-12 11:25 ` Georg Bauhaus 0 siblings, 2 replies; 83+ messages in thread From: Ted Dennison @ 2002-06-10 15:03 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkbsakqfiw.fsf@acm.org>... > dennison@telepath.com (Ted Dennison) writes: > > What that means is that if we were to use XML, we should support > > both user-defined configuration item attributes > > Just because XML supports this, doesn't mean the Config_File API > should. We're looking for a simple subset. If the app decides it needs I'd agree with this statement. However, I'd take it one step further: Just because we *could* use XML doesn't mean we should. We have other simpler options than XML. Supporting the more complex syntax of XML is going to be a burden on both package implementors and config file users. We shouldn't be imposing the extra burden unless we get something good in return that we won't get with a simpler syntax. > > If we are to stick with simple attribute-value pairs, then XML would > > be major overkill. > > In what way? I have a very small package that parses the subset of XML > that I need to meet the Config_File spec (Glib.XML - 671 lines in the > body). What's wrong with that? What's wrong is: 1) It could be *far* smaller than that, if we were parsing a simpler syntax. 2) Its going to cause an explosion of arcane-looking XML cruft in the config files, the vast majority of which is unneeded, except that XML says it has to be there. What's the point of saying <item><key>...</key></item> all the time, if *everything* is an item, and key is the only attribute we ever use? I will cost us, in that it will make the file much harder for humans to read. I'm particuarly thinking of the site maintanence engineers who are the typical users of real-time system configuration files. It also adds a source of errors, as its easy to forget an end tag or transpose a letter somewhere. You really whould have trouble doing that if your only syntax is "=". So again, I think its an important point that we should only do this to ourselves if we are getting something back that we can't get out of a more simple configuration file format. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 15:03 ` Ted Dennison @ 2002-06-10 18:12 ` Stephen Leake 2002-06-12 11:25 ` Georg Bauhaus 1 sibling, 0 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-10 18:12 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > > > If we are to stick with simple attribute-value pairs, then XML would > > > be major overkill. > > > > In what way? I have a very small package that parses the subset of XML > > that I need to meet the Config_File spec (Glib.XML - 671 lines in the > > body). What's wrong with that? > > What's wrong is: > > 1) It could be *far* smaller than that, if we were parsing a simpler > syntax. Um, I don't see how. That's 671 total lines, comments and blanks included! Basically, it's a recursive function, looking for matching <tag></tag>. Really simple. I suppose if I used OpenToken or something, the top level file would be smaller. This file is built on top of Ada.Text_IO. > 2) Its going to cause an explosion of arcane-looking XML cruft in > the config files, the vast majority of which is unneeded, except > that XML says it has to be there. What's the point of saying > <item><key>...</key></item> all the time, if *everything* is an > item, and key is the only attribute we ever use? The file I'm currently generating doesn't look like that; it really is very simple. I posted a sample yesterday. I'll post a full trial implementation sometime soon. > I will cost us, in that it will make the file much harder for humans > to read. I'm particuarly thinking of the site maintanence engineers > who are the typical users of real-time system configuration files. > It also adds a source of errors, as its easy to forget an end tag or > transpose a letter somewhere. You really whould have trouble doing > that if your only syntax is "=". These are valid concerns. But I think you misunderstand just how simple the syntax generated by Glib.XML really is. Of course, it may be that it is not valid XML. > So again, I think its an important point that we should only do this > to ourselves if we are getting something back that we can't get out > of a more simple configuration file format. Yes. I agree. > -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 15:03 ` Ted Dennison 2002-06-10 18:12 ` Stephen Leake @ 2002-06-12 11:25 ` Georg Bauhaus 2002-06-12 15:33 ` Darren New 2002-06-12 17:48 ` Stephen Leake 1 sibling, 2 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-12 11:25 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote: : What's wrong is: : : 1) It could be *far* smaller than that, if we were parsing a simpler : syntax. far by what amount? <item key="the_key">value string of some average length</item> the_key:=value string of some average length 2/3. : <item><key>...</key></item> all the time, if *everything* is an item, : and key is the only attribute we ever use? If this is so, well... You mention real time systems, but I wonder whether a configuration for an AWS application will get anything but messy if it has to be configured with key value pairs only. Ada equivalent: put everything in one big package. I don't understand this verbosity and design aversion in an Ada context :-) : I will cost us, in that it will make the file much harder for humans : to read. Depends. (On the design of the (implicit or explicit) DTD. Of course, with XML being for computers, SGML with all its tag omission features etc. being for humans, this is to be expected, at least if there isn't a decent design.) : I'm particuarly thinking of the site maintanence engineers who could use _any_ XML enabled editing tool to write valid configuration files (where valid refers to XML validation). : as its easy to forget an end tag or : transpose a letter somewhere. the idea behind XML is that you don't have to write tags yourself. That would be the province of the XML application (e.g. editor) or of full SGML, where, e.g. an HTML like list can look like <ul> <li>bla <>the <>foo </ul> instead of XML's <ul> <li>bla</li> <li>the</li> <li>foo</li> </ul> Admittedly, it is _really_ sad that so many XML data floating around make a bad impression by not making use of valuable XML features. Builtin cross referencing, element _types_ with _constraint_ checking, etc. : You really whould have trouble doing that if your only syntax is "=". True, but how does this brevity stop you from making typing errors? How do you check the correctness of the configuration? Where are the namespaces? You would have to search back to the latest section heading or namespace.key=value manespace.kez=valeur -- 3 typos, not easily noted! : if we are getting something back that we can't get out of : a more simple configuration file format. An annotated typed tree is different from a flat anything-list. I think it depends on the application whether a list of a few settings like in environment variables is sufficient or not. Should the decision between very simple Key(i) = value(i) and a grammar driven externally checked configuration be frozen in the API? -- georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 11:25 ` Georg Bauhaus @ 2002-06-12 15:33 ` Darren New 2002-06-12 17:53 ` Stephen Leake ` (2 more replies) 2002-06-12 17:48 ` Stephen Leake 1 sibling, 3 replies; 83+ messages in thread From: Darren New @ 2002-06-12 15:33 UTC (permalink / raw) Georg Bauhaus wrote: > > Ted Dennison <dennison@telepath.com> wrote: > : What's wrong is: > : > : 1) It could be *far* smaller than that, if we were parsing a simpler > : syntax. > > far by what amount? > <item key="the_key">value string of some average length</item> > the_key:=value string of some average length > > 2/3. Ted was talking about the code being smaller, not the config file. It is far easier to split a string at an = than it is to parse even restricted XML. > You mention real time systems, but I wonder whether a configuration > for an AWS application will get anything but messy if it has to > be configured with key value pairs only. Yes, but it will be simple, and relatively easy to edit by hand, which was the point. Every suggestion at something more complex than simple string=string runs into the problem of editing it by hand. > Ada equivalent: put everything > in one big package. Well, that's why the config file has sections and nested heirarchical names and multiple config files per program. > I don't understand this verbosity and design aversion in an Ada context :-) The people editing the config file might not be Ada programmers. > : I will cost us, in that it will make the file much harder for humans > : to read. > > Depends. (On the design of the (implicit or explicit) DTD. No, it doesn't. XML requires balanced start and end tags, it requires quotes in attributes, it requires that less-than and ampersand in PCDATA be escaped, none of which is true for INI formats and all of which is true regardless of the DTD. > : I'm particuarly thinking of the site maintanence engineers > > who could use _any_ XML enabled editing tool to write valid > configuration files (where valid refers to XML validation). Errr... as opposed to using 'cat' to edit INI files? > : as its easy to forget an end tag or > : transpose a letter somewhere. > > the idea behind XML is that you don't have to write tags yourself. > That would be the province of the XML application (e.g. editor) or So why not allow binary in the files, if you need to use a special editor to edit them? I think we're starting to go in circles at this point. I think the question you have to answer clearly, if you're advocating XML, is what benefit does it offer this project above and beyond the capabilities that an INI-format file would offer? > Should the decision between very simple Key(i) = value(i) > and a grammar driven externally checked configuration be frozen > in the API? I think if you're looking for a simple config file API, then yes. If you're looking for full-blown XML with namespaces and cross references and all, you're looking at something best done with a full-blown XML parser, at which point who needs a config file API anyway? -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 15:33 ` Darren New @ 2002-06-12 17:53 ` Stephen Leake 2002-06-13 14:18 ` Ted Dennison 2002-06-12 19:18 ` Georg Bauhaus 2002-06-13 13:53 ` Ted Dennison 2 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-12 17:53 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Ted was talking about the code being smaller, not the config file. > > It is far easier to split a string at an = than it is to parse even > restricted XML. Well, yes. But the difference between a 671 line package and a 100 line package is pretty unimportant, in my view. ><snip> > Depends. (On the design of the (implicit or explicit) DTD. > > No, it doesn't. XML requires balanced start and end tags, it requires quotes > in attributes, it requires that less-than and ampersand in PCDATA be > escaped, none of which is true for INI formats and all of which is true > regardless of the DTD. Good points. quoting quotes is also required. > I think the question you have to answer clearly, if you're advocating XML, > is what benefit does it offer this project above and beyond the capabilities > that an INI-format file would offer? Yes. So far, I see two benefits: 1) A standard small parser is already written; Glib.XML 2) The potential for an application to grow smoothly beyond a simple config file to a full-fledged XML file. Hmm, there is a third benefit; we get to use a current buzzword :). Benefit 1) is not a big deal; it would not be that hard to write another small parser. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 17:53 ` Stephen Leake @ 2002-06-13 14:18 ` Ted Dennison 2002-06-13 16:36 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Ted Dennison @ 2002-06-13 14:18 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<u3cvsmlhy.fsf@gsfc.nasa.gov>... > Yes. So far, I see two benefits: > > 1) A standard small parser is already written; Glib.XML I agree with your assessment (snipped) that this "benifit" actually isn't a huge deal. Writing a parser for the .ini format should be exceedingly simple (perhaps as simple as *using* Glib.XML), and that is what you have to set this against. > 2) The potential for an application to grow smoothly beyond a simple > config file to a full-fledged XML file. I could indeed see that being a minor benifit for a small minority of users. But I hardly think it counterbalances the hours the rest of us will have to spend on the phone explaining XML to users so that they can reconfigure their application. I'm thinking if we go with XML we will probably have to mandate a GUI config file editor (like Microsoft's regedt) be distributed with a Free license (so it can be given to users without incurring extra fees) with every compiler. I can't think of any other way to make up for loosing user-editability enough to make XML a viable option. > Hmm, there is a third benefit; we get to use a current buzzword :). If I really cared about such things, I'd be over in comp.lang.c# (or whatever) helping with their standard library. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - (temporarily down) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 14:18 ` Ted Dennison @ 2002-06-13 16:36 ` Stephen Leake 2002-06-14 3:27 ` Ted Dennison 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-13 16:36 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > news:<u3cvsmlhy.fsf@gsfc.nasa.gov>... > > Yes. So far, I see two benefits: > > > > 1) A standard small parser is already written; Glib.XML > > I agree with your assessment (snipped) that this "benifit" actually > isn't a huge deal. Writing a parser for the .ini format should be > exceedingly simple (perhaps as simple as *using* Glib.XML), and that > is what you have to set this against. Yeah. I'll implement a Java properties style file format next, to get a clear understanding of the trade off. > > 2) The potential for an application to grow smoothly beyond a > > simple config file to a full-fledged XML file. > > I could indeed see that being a minor benifit for a small minority of > users. But I hardly think it counterbalances the hours the rest of us > will have to spend on the phone explaining XML to users so that they > can reconfigure their application. I'm beginning to agree with you. Requiring users to type & is too much. > I'm thinking if we go with XML we will probably have to mandate a > GUI config file editor (like Microsoft's regedt) be distributed with > a Free license (so it can be given to users without incurring extra > fees) with every compiler. I can't think of any other way to make up > for loosing user-editability enough to make XML a viable option. That is a choice, but then there isn't much difference from a 'real' registry. > > Hmm, there is a third benefit; we get to use a current buzzword > > :). > > If I really cared about such things, I'd be over in comp.lang.c# (or > whatever) helping with their standard library. Well, you have to use the _right_ buzzwords :). I was excited to be on the bandwagon for once; sometimes I get tired of swimming upstream all the time :(. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 16:36 ` Stephen Leake @ 2002-06-14 3:27 ` Ted Dennison 2002-06-14 15:54 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Ted Dennison @ 2002-06-14 3:27 UTC (permalink / raw) Stephen Leake wrote: > dennison@telepath.com (Ted Dennison) writes: >>I could indeed see that being a minor benifit for a small minority of >>users. But I hardly think it counterbalances the hours the rest of us >>will have to spend on the phone explaining XML to users so that they >>can reconfigure their application. > > I'm beginning to agree with you. Requiring users to type & is too > much. Perhaps it would be a good idea to support XML saving and restoring as a kind of "import/export" function. That way people could run the config file through XML tools they might have if they want to do that for some reason, without it being the default. I suppose another "We're *all* right!" weasel option would be to put multiple file format save/restores in child packages. Perhaps we could even make a save/restore tagged type that folks can supply, with (preferably) something producing human-readable output as the default. > I was excited to be on the bandwagon for once; sometimes I get tired > of swimming upstream all the time :(. At least all that exercise is good for your heart.... :-) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-14 3:27 ` Ted Dennison @ 2002-06-14 15:54 ` Stephen Leake 0 siblings, 0 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-14 15:54 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Perhaps it would be a good idea to support XML saving and restoring as > a kind of "import/export" function. That way people could run the > config file through XML tools they might have if they want to do that > for some reason, without it being the default. Since there are so many choices for how to represent config file information as XML, I don't think I want to do this. People can write their own converter, using the reference Config_Files implementation (assuming we end up with a non-XML standard). > I suppose another "We're *all* right!" weasel option would be to put > multiple file format save/restores in child packages. Perhaps we > could even make a save/restore tagged type that folks can supply, > with (preferably) something producing human-readable output as the > default. Too many standards spoil the code :). > > I was excited to be on the bandwagon for once; sometimes I get > > tired of swimming upstream all the time :(. > > At least all that exercise is good for your heart.... :-) :). -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 15:33 ` Darren New 2002-06-12 17:53 ` Stephen Leake @ 2002-06-12 19:18 ` Georg Bauhaus 2002-06-13 13:53 ` Ted Dennison 2 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-12 19:18 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : Ted was talking about the code being smaller, not the config file. Sorry, I've missed it. : Errr... as opposed to using 'cat' to edit INI files? ed or edlin or some such will do in any case, =-text or XML text, provided such a thing is present in the toaster :-) : So why not allow binary in the files, if you need to use a special editor to : edit them? Because you needn't use a special editor, but you can. (For example at some remote site.) : you're looking at something best done with a full-blown XML parser, at which : point who needs a config file API anyway? A full blown XML parser doesn't force us to use a completely unrestricted DTD. The restrictions can be reflected in the DTD. It doesn't force the configured program to include it. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 15:33 ` Darren New 2002-06-12 17:53 ` Stephen Leake 2002-06-12 19:18 ` Georg Bauhaus @ 2002-06-13 13:53 ` Ted Dennison 2002-06-13 15:26 ` Georg Bauhaus 2002-06-13 16:39 ` Darren New 2 siblings, 2 replies; 83+ messages in thread From: Ted Dennison @ 2002-06-13 13:53 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3D0769F7.68F5BD9C@san.rr.com>... > Ted was talking about the code being smaller, not the config file. > > It is far easier to split a string at an = than it is to parse even > restricted XML. It's always nice when at least one person understands what I write. :-) > The people editing the config file might not be Ada programmers. My big worry in all this is that we will go through all this effort, get something approved, and I will never be able to use it because the syntax will be to complicated for our customers to deal with. I don't think I'm alone on this issue. Whatever you propose, picture yourself on the phone trying to explain to a (non-programmer) customer how to add or change a value. (XML) > in attributes, it requires that less-than and ampersand in PCDATA be > escaped, none of which is true for INI formats and all of which is true Ewwww. I'd forgotten about that issue. Do we (assming XML use) actually intend to enforce this bit of nastyness to maintain theoretical XML compliance, or do we bend the rules to make it a bit easier to use for people who aren't XML experts? I'd say if we hose them with XML in the first place, we might as well go all the way and do it right. :-( > I think the question you have to answer clearly, if you're advocating XML, > is what benefit does it offer this project above and beyond the capabilities > that an INI-format file would offer? ...that makes worth: o Extra facility implementation complexity o More error-prone config syntax o Less (human) readable files o Essentially making the configuration files unsuable by anyone who isn't a programmer -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - (temporarily down) ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 13:53 ` Ted Dennison @ 2002-06-13 15:26 ` Georg Bauhaus 2002-06-13 16:39 ` Darren New 1 sibling, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-13 15:26 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote: :> It is far easier to split a string at an = than it is to parse even :> restricted XML. : : : It's always nice when at least one person understands what I write. : :-) Isn't the goal to get useful information for configuring our software? Or about maximization of easiness of configuration file parsing? -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 13:53 ` Ted Dennison 2002-06-13 15:26 ` Georg Bauhaus @ 2002-06-13 16:39 ` Darren New 2002-06-13 17:06 ` Georg Bauhaus 2002-06-13 17:54 ` Georg Bauhaus 1 sibling, 2 replies; 83+ messages in thread From: Darren New @ 2002-06-13 16:39 UTC (permalink / raw) Ted Dennison wrote: > Ewwww. I'd forgotten about that issue. Do we (assming XML use) > actually intend to enforce this bit of nastyness to maintain > theoretical XML compliance, or do we bend the rules to make it a bit > easier to use for people who aren't XML experts? The minute you bend the rules, you might as well throw out the pre-written XML parsers and all the XML tools. The moment you don't escape < in a PCDATA, you're screwed. Georg Bauhaus wrote: > Isn't the goal to get useful information for configuring our software? > Or about maximization of easiness of configuration file parsing? I think the goal is to get a useful configuration facility that allows hand-editing of configuration files by non-programmers without the need for a specialized editor. > Understanding starts at understanding the contents and the structure, > not the syntax. That's essential. No, it starts at the syntax, because if you can't read it, you can't even learn the contents and structure. As proof, consider a configuration file that's a dump of a stream. Lots of structure, all the contents you need, opaque syntax. Take a look and tell me what's in it. > How does one capture dependencies of settings in kv pairs? In documentation, just like you would in XML. If you think XML can show the relationship between keys and values, such that key1+key2+key3 must add up to less than 80, and filename must be of the length that equals key1+key2+key3, then maybe you should teach us how to do that in an XML file that couldn't be done in a text file. Of course, a simple example would suffice. > Incidentally, comments aren't lost in XML and each comment > belongs to an element. Namely, the element in which it appears. OK, here's the problem with that. Gobal config file: <foo> <!-- Comment for foo --> <key name="bar">value from global config file</key> <!-- Another comment for foo --> </foo> Local config file: <foo> <!-- Local comment --> <key name="bar">overriding bar value</key> <!-- local comment the second --> <key name="baz">new local baz value</key> <!-- Yet another local comment --> </foo> Now, in my API, I add the key "pock" to foo, with the value "A winner!", and I want to put a comment before it. Please show what that call looks like, and explain how the library decides to keep the local comments and/or the global config file comments, when I save the local config file back out. Then reconsider, when the "Comment for foo" actually says "bar is a parameter that means blah blah blah", and the "Local comment" says "Darren's local directory". It sounds like by using XML, you're introducing all kinds of ordering dependencies in the file, treating the database as an XML structure rather than something closer to a hashtable, and so you have to decide how to merge two XML files and output a new one with the same semantics. Difficult to do, in the case of comments. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 16:39 ` Darren New @ 2002-06-13 17:06 ` Georg Bauhaus 2002-06-13 17:43 ` Darren New 2002-06-13 17:54 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-13 17:06 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: :> Understanding starts at understanding the contents and the structure, :> not the syntax. That's essential. : : No, it starts at the syntax, because if you can't read it, you can't even : learn the contents and structure. O.K. In the sense that if you can't read it you cannot start to understand it. Should have said so, sorry for the sloppiness. :> How does one capture dependencies of settings in kv pairs? : : In documentation, just like you would in XML. No I wouldn't, not in all cases. At least I wouldn't where a grammar allows me to require dependency checked data. (The other issues you will have to ask Dr. Leif. :-) :-) :-) Sorry, couldn't resist.) Sure I wouldn't want to try to implement a compiling Turing machine in either keys and values or in XML. : Of course, a simple example would suffice. A simple example (not for number addition in XML, of course) is that a child element can be required by the DTD or an attribute value must be present (again required by the DTD) with a value of either "yes" or "no". -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 17:06 ` Georg Bauhaus @ 2002-06-13 17:43 ` Darren New 2002-06-14 15:56 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-13 17:43 UTC (permalink / raw) Georg Bauhaus wrote: > No I wouldn't, not in all cases. At least I wouldn't where a grammar > allows me to require dependency checked data. I don't think DTDs allow you to say things like certain values must be within certain ranges, etc. If DTDs were that powerful, I'd start to agree with you. > : Of course, a simple example would suffice. > > A simple example (not for number addition in XML, of course) > is that a child element can be required by the DTD > or an attribute value must be present (again required by the > DTD) with a value of either "yes" or "no". Well, yes. But I meant something more complex, since I don't think anyone wants to teach their users XML DTD syntax to explain that this has to be "yes" or "no." For example, you can't say "the value of this field must be a dotted-quad IPv4 address" with a DTD. Even so, anything you describe in a DTD you'll also have to describe in prose documentation, plus I don't think any of the existing Ada XML libraries will validate against a DTD, will they? -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 17:43 ` Darren New @ 2002-06-14 15:56 ` Georg Bauhaus 0 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-14 15:56 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : I don't think DTDs allow you to say things like certain values must be : within certain ranges, etc. If DTDs were that powerful, I'd start to agree : with you. They aren't in all cases, that's why people invented schemata, but for example <!ATTLIST thing switch (on | off) "on" connections (1 | 2 | 3 | 4) #REQUIRED ident ID #IMPLIED > will give you a thing with a switch which is on by default, with one of two possible values, 4 possible values for a connection attribute and a unique identifier. : But I meant something more complex, since I don't think anyone : wants to teach their users XML DTD syntax to explain that this has to be : "yes" or "no." Sure, the idea is, again, that computers will have swallowed the DTD and people constructing or modifying configuration data won't be able to enter just about anything. Depending on whether there is a specialized configuration application/applet/... or not, something more complex can be done or not. : plus I don't think : any of the existing Ada XML libraries will validate against a DTD, will : they? Afaik, some do. Lots of software libraries available for binding and studying, e.g. SP, fxp, libxml2, ... ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 16:39 ` Darren New 2002-06-13 17:06 ` Georg Bauhaus @ 2002-06-13 17:54 ` Georg Bauhaus 2002-06-13 18:31 ` Darren New 1 sibling, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-13 17:54 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: :> Incidentally, comments aren't lost in XML and each comment :> belongs to an element. Namely, the element in which it appears. : : OK, here's the problem with that. Agreed. It wasn't my intention to be an advocate of convention driven comment-thing association. In particular when semantics isn't captured anywhere but in the natural language of the comment, this becomes rather difficult for computer languages, yes. Insertion of commented items will have the potential of destroying essential order and thus sense. Bad Thing. That leaves the ends of lists, right? Of course if information _is_ bound to some item, that could be made explicit. Somewhat like coments in Lisp or python functions. : Gobal config file: : Local config file: : Now, in my API, I add the key "pock" to foo, with the value "A winner!", and : I want to put a comment before it. Please show what that call looks like, : and explain how the library decides to keep the local comments and/or the : global config file comments, when I save the local config file back out. Uhm, you have named the things to consider for a policy. Have I missed something? Merging, overriding, combining, how should that appear in an API independent of any file format? : It sounds like by using XML, you're introducing all kinds of ordering : dependencies in the file, No that is introduced by using comments as data and has nothing to do with XML. Are there no ordering implications with two config files and a pook in ; comment kv ... :treating the database as an XML structure rather : than something closer to a hashtable, Yes. That is what I would like to see. Something that is different from but including lookup tables. : and so you have to decide how to merge : two XML files and output a new one with the same semantics. Indeed. : Difficult to do, in the case of comments. Independent of whether pairs are stored linearly ordered in INI file format, or in XML, no? -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 17:54 ` Georg Bauhaus @ 2002-06-13 18:31 ` Darren New 2002-06-14 16:04 ` Stephen Leake 2002-06-14 17:03 ` Georg Bauhaus 0 siblings, 2 replies; 83+ messages in thread From: Darren New @ 2002-06-13 18:31 UTC (permalink / raw) Georg Bauhaus wrote: > Uhm, you have named the things to consider for a policy. Have I missed > something? Merging, overriding, combining, how should that appear in > an API independent of any file format? Well, that's the question. I think it's something much easier to answer for INI files than XML files. > : It sounds like by using XML, you're introducing all kinds of ordering > : dependencies in the file, > > No that is introduced by using comments as data and has nothing to > do with XML. Uh, sure it does. The order of tags in XML is quite explicitly important. > :treating the database as an XML structure rather > : than something closer to a hashtable, > > Yes. That is what I would like to see. Something that is different > from but including lookup tables. Well, propose something. :-) > : Difficult to do, in the case of comments. > > Independent of whether pairs are stored linearly ordered in INI file > format, or in XML, no? Difficult to do if you use XML, because XML has a particular semantics for comments. Easy to do for INI because you get to make up yourself what those semantics are. In an INI format, I could say "the comment always attaches to whatever non-comment object comes next." So you'd have # This section is for colors [Colors] # The background color bg=23 # The forground color fg=87 Here, if I used the API to delete "fg" and wrote it back out, it's obvious what happens to the comment. In XML, I could wind up with comments most anywhere, including multiple comments attached to the same object, interspersed with "real" tags, where you'd expect the comment to be about the tag. Unless you're proposing that the above would translate to <colors> <!-- This section is for colors --> <key name="bg"> <!-- The background color --> 23 </key> <key name="fg"> <!-- The foreground color --> 87 </key> </colors> I guess that's not too bad, but it does seem like overkill. And of course, then you wind up with the possibilities of something like <key name="brush"> <!-- First the name of the brush --> round airbrush <!-- Then the color --> green <!-- You can pick alpha blend modes here too --> </key> I'm just saying that I think the semantics of the kind of thing an INI file would have to deal with in the API are pretty darn straightforward. The kinds of things an XML-based file would have to deal with are far more complicated. XML is tremendous overkill for an INI-like API. I think many people arguing against XML don't understand how it would particularly help an INI-like API. Perhaps offering an idea of the API you're envisioning would help it move forward. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 18:31 ` Darren New @ 2002-06-14 16:04 ` Stephen Leake 2002-06-14 16:48 ` Darren New 2002-06-14 17:03 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-14 16:04 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Georg Bauhaus wrote: > > Uhm, you have named the things to consider for a policy. Have I missed > > something? Merging, overriding, combining, how should that appear in > > an API independent of any file format? I agree with this; I'm not sure how to put comments in the API. > Well, that's the question. I think it's something much easier to > answer for INI files than XML files. Ok, could you provide an example implementation? I'll be posting a Java properties style after the weekend, without comments. Maybe you could start with that. > > : It sounds like by using XML, you're introducing all kinds of > > : ordering dependencies in the file, > > > > No that is introduced by using comments as data and has nothing to > > do with XML. > > Uh, sure it does. The order of tags in XML is quite explicitly important. Well, the order of data tag 'foo' vs comment tag 'bar' is not important, unless the DTD says it is. > Difficult to do if you use XML, because XML has a particular semantics for > comments. But we don't _have_ to use that for Config_File comments. I think Config_File comments as attributes makes the associations easier to keep straight. But it would probably be somewhat confusing to read :(. > Easy to do for INI because you get to make up yourself what those > semantics are. In an INI format, I could say "the comment always > attaches to whatever non-comment object comes next." So you'd have > > # This section is for colors > [Colors] > # The background color > bg=23 > # The forground color > fg=87 > > Here, if I used the API to delete "fg" and wrote it back out, it's obvious > what happens to the comment. Ok, I like that. It breaks your earlier example where you had a comment following a value, but we can't have everything. > I'm just saying that I think the semantics of the kind of thing an INI file > would have to deal with in the API are pretty darn straightforward. I bet we could come up with an implementation of the same semantics for XML. Note that neither of these semantics will support arbitrary placement of comments by direct editing; the user has to know the rules. > The kinds of things an XML-based file would have to deal with are > far more complicated. But we don't have to support them all. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-14 16:04 ` Stephen Leake @ 2002-06-14 16:48 ` Darren New 0 siblings, 0 replies; 83+ messages in thread From: Darren New @ 2002-06-14 16:48 UTC (permalink / raw) Stephen Leake wrote: > I agree with this; I'm not sure how to put comments in the API. I would carry a possibly-empty string for each key and section. Allow calls to set or retrieve the comment for a particular key or section. > > Well, that's the question. I think it's something much easier to > > answer for INI files than XML files. > > Ok, could you provide an example implementation? I'll be posting a > Java properties style after the weekend, without comments. Maybe you > could start with that. I'll look, but I'm kind of busy. :-) > > Uh, sure it does. The order of tags in XML is quite explicitly important. > > Well, the order of data tag 'foo' vs comment tag 'bar' is not > important, unless the DTD says it is. Fair enough. But if the order isn't important in the DTD, then you can't tell what item the comment refers to, so the order *becomes* important, in the sense that the API has to say where in the list of things output to the file the comments belong. <foo> <comment> This is the color </comment> <color> red </color> <comment> This is the brightness </comment> <brightness> 54% </brightness> </foo> What's the DTD for foo? <!ELEMENT foo (comment|color|brightness)> Even if the DTD says the order is unimportant, the order is important. :-) > Ok, I like that. It breaks your earlier example where you had a > comment following a value, but we can't have everything. I don't think that was *my* example, but OK. You could also make it follow the value if it fit. That's the advantage of attaching it to a key instead of to some position in a list. > > I'm just saying that I think the semantics of the kind of thing an INI file > > would have to deal with in the API are pretty darn straightforward. > > I bet we could come up with an implementation of the same semantics > for XML. But then why use XML if it's just going to make it more complex without giving you any more powerful semantics? > Note that neither of these semantics will support arbitrary placement > of comments by direct editing; the user has to know the rules. Well... the rule is that the comment talks about the next thing. :-) > > The kinds of things an XML-based file would have to deal with are > > far more complicated. > > But we don't have to support them all. You have to certainly at least detect them. And if you're not going to support them, why use XML? -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 18:31 ` Darren New 2002-06-14 16:04 ` Stephen Leake @ 2002-06-14 17:03 ` Georg Bauhaus 2002-06-14 17:22 ` Darren New 1 sibling, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-14 17:03 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : the order of tags in XML is quite explicitly important. Unless the DTD says it doesn't matter (in repeated alternatives). (Otherwise it would be impossible to have mixed content, like for example emphasized text before or after a code sample in an HTML paragraph). SGML is more convenient in this respect, since it has not only comma and bar for sequence and alternative, but also ampersand (and) for "all in any order" in content models. : 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 --. : "the comment always attaches to : whatever non-comment object comes next." Why shouldn't that be possible with XML? parent / / \ \ child1 comment2a comment2b child2 ... : [...] : I guess that's not too bad, but it does seem like overkill. XML _is_ verbose, and I've come to like some verbosity :-) : XML is tremendous overkill for an INI-like API. It sure is. But... : I think many : people arguing against XML don't understand how it would particularly help : an INI-like API. This isn't what I would want it to do, it should (if necessary) help overcome the limitations of sectioned key-value settings. : 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. whereas <tools> <brush type="airbrush" shape="circle" color="green"/> ... </tools> makes this unnecessary. Much like named parameters in Ada. 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)). Of course, building the software for access paths in configuration trees might not look as straightforward if all the XML handling has to be invented. But a lot of effort has already gone into building XML software, we only need to reuse it :-) I like TED's idea of child packages, but have to think about this some more. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-14 17:03 ` Georg Bauhaus @ 2002-06-14 17:22 ` Darren New 2002-06-18 15:20 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-14 17:22 UTC (permalink / raw) Georg Bauhaus wrote: > > Darren New <dnew@san.rr.com> 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. <body> <h1> First </h1> <h1> Second </h1> </body> <body> <h1> Second </h1> <h1> First </h1> </body> 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 > <tools> > <brush type="airbrush" shape="circle" color="green"/> > ... > </tools> > > 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-14 17:22 ` Darren New @ 2002-06-18 15:20 ` Georg Bauhaus 2002-06-18 15:37 ` Darren New 0 siblings, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-18 15:20 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: just a little update: [tools] : brush.type=airbrush : brush.shape=round : brush.color=green : :> <tools> :> <brush type="airbrush" shape="circle" color="green"/> :> ... :> </tools> : : OK. So we add a little more to the ini format. We still don't get into : matched-tags hell etc. To each his own hell :-) (broken lines with a fpt value (incl dot), an '=' character in the value text etc...) : : 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? we could reconcile the two formats, I think, like so. Suppose the configuration is visible through some protected object 'conf', and suppose access to some specific value is coded using a hashing scheme: conf.get("[tools]brush.color"); -- or some such This is very similar to an XPath expression conf.get("/tools/brush/@color"); Does this open up an opportunity to build an abstraction? -- Georg : -- --- Microsoft Windows--a fresh perspective on information hiding ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-18 15:20 ` Georg Bauhaus @ 2002-06-18 15:37 ` Darren New 2002-06-18 18:20 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-18 15:37 UTC (permalink / raw) Georg Bauhaus wrote: > Does this open up an opportunity to build an abstraction? Most certainly. I was thinking more along the lines of val := conf.get("Section", "super.subkey", "default value goes here"); conf.set("OtherSection", "yet.another.key", "new value here", "Optional comment goes here, describing yet.another.key"); conf.new_section("WindowSizes", "Another Optional Comment"); That's why I wanted to see your idea of what the API would look like. I'm trying to see what XML would be supporting that you can't support easily in the INI format. So far, all I've seen is "here's how the INI should look" and responses of "You can do that in XML too." :-) So what are you suggesting the XML-based API should look like? -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-18 15:37 ` Darren New @ 2002-06-18 18:20 ` Georg Bauhaus 2002-06-18 19:11 ` Stephen Leake 2002-06-18 21:47 ` Darren New 0 siblings, 2 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-18 18:20 UTC (permalink / raw) Darren New <dnew@san.rr.com> 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-18 18:20 ` Georg Bauhaus @ 2002-06-18 19:11 ` Stephen Leake 2002-06-18 21:47 ` Darren New 1 sibling, 0 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-18 19:11 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Darren New <dnew@san.rr.com> 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? :-) If you are modifying the INI file format by adding "." to keys, that's not the INI file format, and we might as well use the Java property format (which I did in my latest implementation). Please look at that and see if you like it. > 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. Yes. > Unless I want all configuration data for one subsection or one item, > for which see below. I didn't implement this, but it is in the requirements (return a list of the next-level items at a given level). > 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 see the distinction, but I'm not clear when it is relevant. Since the application has to know the name and type of everything in the config file, it knows what to ask for all the time. > 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? Requirement 16; data retrieval is independent of the key order in the file. So the in-memory copy of the data has to group all the brush.xxx values together; I used a tree structure. > You whould have to keep track of them all, afaics, in a sorted map? Yes, or a tree. Some sort of ordered structure is required. > 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. That is a requirement on the file format. But we actually need a requirement on the in-memory copy. That turns out to be easier. > 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). Requirement 17; multiple copies are allowed on read (last one is saved). Only one is written. Presumably, when the app writes the config file, it will be properly sorted and/or grouped. > 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.) Yes, I'm not clear whether we should allow/require multi-line values with the Java properties format. I would hope that there are no "overly long values" in a config file. In general, my approach to binary data like pictures would be to put the path to the picture file in the config file. Do you have an example where that is not the right approach? > 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 :-) I'll settle for novice-proof :). Clearly, it is harder to screw up the Java property syntax than the XML syntax. We have to assume some level of competence on the part of the user. > How are the configuration values stored internally? In a hash table > indexed by dotted names? It's up to the implementer. The API requirements don't actually say, but my example implementations say keys are dotted names, and the internal format is a tree. > 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? Yes. Although if you use a hash table on the full key, you are not "parsing", you are "hashing". My implementations do "parse" the keys for each lookup. That was easy to do; if it turns out to be to slow, somebody can do a hash table or something else. > If the values are stored in an tree, wouldn't this effort in effect > start building DOM support for INI files? :-) Yes. I think that's implied by the current requirements. > : 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.) I prefer one standard file format, so different apps can share them, and people get used to editing one format, and the implementation code gets tested more. If your app outgrows the Config_File spec, and you need XML, you can convert the files once, and start using a real XML parser. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-18 18:20 ` Georg Bauhaus 2002-06-18 19:11 ` Stephen Leake @ 2002-06-18 21:47 ` Darren New 2002-06-19 11:31 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-18 21:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-18 21:47 ` Darren New @ 2002-06-19 11:31 ` Georg Bauhaus 2002-06-19 15:13 ` Stephen Leake 2002-06-19 16:43 ` Darren New 0 siblings, 2 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-19 11:31 UTC (permalink / raw) Darren New <dnew@san.rr.com> 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-19 11:31 ` Georg Bauhaus @ 2002-06-19 15:13 ` Stephen Leake 2002-06-19 21:14 ` Georg Bauhaus 2002-06-19 16:43 ` Darren New 1 sibling, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-19 15:13 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Darren New <dnew@san.rr.com> 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! You're welcome. Can you give more detail about what is missing? I'm not clear what operations are implied by "administer". We have read, write, delete, and list. What other operations do you want? > 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") I guess "de_CH" is a language specifier? That sounds like a neat idea. Although it would be simpler to have a separate config file for each language. Would you be changing language on the fly during the program? I guess a "translator" program would. But then you could just open both config files (the English one and the German one). > 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. > 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. 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. > 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, 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. > 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".) Yes, it's a problem. Not one Config_Files is trying to solve. > :> : 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. Does my grace-config_files_java.ads meet your needs? > : 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? You have said exactly the opposite, just 17 lines above. Please post specific suggestions for changes to the proposed API. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-19 15:13 ` Stephen Leake @ 2002-06-19 21:14 ` Georg Bauhaus 2002-06-20 14:38 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-19 21:14 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> 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 <x><y lang="de_CH">...</y></x> 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 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-19 21:14 ` Georg Bauhaus @ 2002-06-20 14:38 ` Stephen Leake 2002-06-20 16:02 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-20 14:38 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> 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. Ok. > 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. They can do that now by writing to a string, and calling Write_String. Or, we could add something like: generic type Private_Type is private; with function To_String (Item : in Private_Type) return String; procedure Write_Private (Config : in out Configuration_Type; Key : in String; Value : in Private_Type; Error_Handling : in Error_Handling_Type := Ignore); I had that in originally, but took it out because it seemed to encourage people to use a non-standard format in the config file. But since people can get around that by just calling Write_String, maybe it's worth putting back in. Although I gather you are saying you'd be happy if I _only_ had Write_String, without any generics. > :> 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.) Ok. So I think you agree the current spec is ok here, and we don't need to add anything special for languages (or "localization" in general). > : 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 <x><y lang="de_CH">...</y></x> in an XML file. Well, yes, we could define a special support for languages in XML. I don't see how it's worth it, in the Config_File context. > 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? I'd like to have one standard file format. You can always add a child package to implement a non-standard format. I wouldn't mind moving enough of the body into the private part of the spec to make that easier. > : 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. Well, if you have a "validating XML editor" sitting around, that would make things easy. I didn't think such things existed. In the absence of that, I don't think it's very hard to build a special editor for config files using the Java property format. Come to think of it, somebody in the Java community has probably done just that. > 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.) The idea is that the installer for the app using the config file writes a "sane" config file. Then the user can edit it if they need to (like if their Windows disks get renamed). You do have to write the installer for your app. > :> 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 :-) Well, the goal is that the API is independent of the file format. If we choose ini files, we can't have mult-level keys; that is one impact on the API. Other than that, I have not seen any impact of the file format on the API, given the other requirements on the API. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-20 14:38 ` Stephen Leake @ 2002-06-20 16:02 ` Georg Bauhaus 2002-06-20 20:37 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Georg Bauhaus @ 2002-06-20 16:02 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote: : generic : type Private_Type is private; : with function To_String (Item : in Private_Type) return String; : procedure Write_Private I like this (a lot indeed). : Although I gather you are saying you'd be happy if I _only_ had : Write_String, without any generics. No, no, it's nice to have some flexibility for coping with different situations. If there is a notion of standard configuration value types, it seems like a good thing to have corresponding standard operations. Write_Private will add a known way of writing in non-standard situations. It's good to have it as part of the API because maintainers will likely succeed in finding the responsible To_String actual. No per-application names, no guesswork required, a documented way at this end. :> file, or to <x><y lang="de_CH">...</y></x> in an XML file. : : Well, yes, we could define a special support for languages in XML. I : don't see how it's worth it, in the Config_File context. I was rather thinking about the difference between children of a section and properties of a section, not about languages in particular, this was just an example. But since properties can be mapped to children (of different specific types actually (in a DOM based implementation of the API)) there is no problem. : I'd like to have one standard file format. You can always add a child : package to implement a non-standard format. I wouldn't mind moving : enough of the body into the private part of the spec to make that : easier. Which parts? AFAICS now, this won't be necessary, at least in the case of DOM. For example, most of the tree related functions are already available. : Well, if you have a "validating XML editor" sitting around, that would : make things easy. I didn't think such things existed. Various. (Actually, (require 'psgml) mode for Emacs (and then turning on xml-mode) is a good start, but of course this is an option for Emacs users only.) -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-20 16:02 ` Georg Bauhaus @ 2002-06-20 20:37 ` Stephen Leake 2002-06-21 16:24 ` Ted Dennison 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-20 20:37 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote: > : generic > : type Private_Type is private; > : with function To_String (Item : in Private_Type) return String; > : procedure Write_Private > > I like this (a lot indeed). > > : Although I gather you are saying you'd be happy if I _only_ had > : Write_String, without any generics. > > No, no, it's nice to have some flexibility for coping with > different situations. If there is a notion of standard configuration > value types, it seems like a good thing to have corresponding standard > operations. > Write_Private will add a known way of writing in non-standard > situations. It's good to have it as part of the API because > maintainers will likely succeed in finding the responsible > To_String actual. No per-application names, no guesswork required, > a documented way at this end. Ok, I'll put this back in. With a caveat that the string may _not_ have embedded newlines. > : I'd like to have one standard file format. You can always add a child > : package to implement a non-standard format. I wouldn't mind moving > : enough of the body into the private part of the spec to make that > : easier. > > Which parts? AFAICS now, this won't be necessary, at least > in the case of DOM. For example, most of the tree related > functions are already available. Oh, yes. In the XML version, that's true. But in the Java properties version, it isn't. So I'd be willing to make the "tree related" functions visible in the Java version. > : Well, if you have a "validating XML editor" sitting around, that > : would make things easy. I didn't think such things existed. > > Various. (Actually, (require 'psgml) mode for Emacs (and then turning on > xml-mode) is a good start, but of course this is an option for Emacs > users only.) Hmm. Ok. That makes XML more acceptable. Sigh :). -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-20 20:37 ` Stephen Leake @ 2002-06-21 16:24 ` Ted Dennison 2002-06-24 14:11 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Ted Dennison @ 2002-06-21 16:24 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uofe5sn31.fsf@gsfc.nasa.gov>... > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > > Various. (Actually, (require 'psgml) mode for Emacs (and then turning on > > xml-mode) is a good start, but of course this is an option for Emacs > > users only.) > > Hmm. Ok. That makes XML more acceptable. Sigh :). As much as I think everyone should be using Emacs, I don't think you can force this. The file ought to be perfectly editable by someone using their OS's "Notepad" equivalent. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-21 16:24 ` Ted Dennison @ 2002-06-24 14:11 ` Stephen Leake 0 siblings, 0 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-24 14:11 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > news:<uofe5sn31.fsf@gsfc.nasa.gov>... > > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > > > Various. (Actually, (require 'psgml) mode for Emacs (and then turning on > > > xml-mode) is a good start, but of course this is an option for Emacs > > > users only.) > > > > Hmm. Ok. That makes XML more acceptable. Sigh :). > > As much as I think everyone should be using Emacs, I don't think you > can force this. The file ought to be perfectly editable by someone > using their OS's "Notepad" equivalent. Agreed. I said "more acceptable", not "acceptable" :). And he implied there were other XML editors besides Emacs. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-19 11:31 ` Georg Bauhaus 2002-06-19 15:13 ` Stephen Leake @ 2002-06-19 16:43 ` Darren New 2002-06-19 20:33 ` Georg Bauhaus 1 sibling, 1 reply; 83+ messages in thread From: Darren New @ 2002-06-19 16:43 UTC (permalink / raw) Georg Bauhaus wrote: > : 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? Yes. But what are we more concerned with? The file format, or what you can do with the file format? If the file format is already fixed, then trying to come up with the best API to manipulate it is a worthwhile exercise. When the question is "what are we doing here", assuming the file format is fixed is probably a bad idea. I suspect it's so obvious to you how you'd use something like this that some of us appear very dense or blind or something. It's simply that you already have a good idea of the API in your head you just haven't revealed. Clearly everything in Stephen's discussion could be implemented either way. You haven't said just what it is you couldn't implement with a format less complex than XML. That's what I'm looking for. -- 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. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-19 16:43 ` Darren New @ 2002-06-19 20:33 ` Georg Bauhaus 0 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-19 20:33 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : : I suspect it's so obvious to you how you'd use something like this that some : of us appear very dense or blind or something. Please, not at all, in fact (as always, no?) you have reminded me of some things to consider. : you haven't said just what it is you couldn't implement with a format less : complex than XML. That's what I'm looking for. Point is that personally I am fine with a complex format or a less complex format. What's bothering me is not so much what can be implemented in either format _for Config_Files.ads_, or how the application programmer would use the subprograms, but it is that the configuration process consists of more than an API, a file format, and text editors. How can I improve the "human aspect" of configuration processes using what is available with some file format? (my reply to Stephen has a few words on this, I hope) The current API has dotted notation. That's a very clear, powerful and manageable thing from an application's point of view, Stephen has working software for property files and XML files. I have nothing to complain here. If you can say that dotted notation in the config file _itself_ is likely not a problem at all for your usual configuration personnel, then don't weigh my words too much, maybe my needs are too far reaching for the average Ada application (or way off :). -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 11:25 ` Georg Bauhaus 2002-06-12 15:33 ` Darren New @ 2002-06-12 17:48 ` Stephen Leake 2002-06-13 7:42 ` Tarjei T. Jensen 1 sibling, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-12 17:48 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > the idea behind XML is that you don't have to write tags yourself. If we take that literally, then we should not use XML for config files. It is a requirement that config files be editable by "any old text editor". However, I think a sufficiently small subset of XML is ok. I'll be posting a complete example Real Soon Now :). > <snip> > An annotated typed tree is different from a flat anything-list. > I think it depends on the application whether a list of a few > settings like in environment variables is sufficient or not. Yes, it does depend on the application. But for config files, we need to find the right compromise. The Win32 registry or Gnome gconf provide a fully annotated typed tree. So I think config files don't need to. > Should the decision between very simple Key(i) = value(i) and a > grammar driven externally checked configuration be frozen in the > API? No, that choice should be transparent to the Config Files API. But we do need a Config Files file format standard, so any implementation can read any Config File. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-12 17:48 ` Stephen Leake @ 2002-06-13 7:42 ` Tarjei T. Jensen 2002-06-13 13:53 ` Georg Bauhaus 2002-06-13 14:10 ` Stephen Leake 0 siblings, 2 replies; 83+ messages in thread From: Tarjei T. Jensen @ 2002-06-13 7:42 UTC (permalink / raw) Stephen Leake wrote: > However, I think a sufficiently small subset of XML is ok. I'll be > posting a complete example Real Soon Now :). Aaarrrggggghhhhhhhh!!!!!!!!! When will people learn that config files should be readable and understandable. There is a lot of misery created by computer programmers just so that the files should be easy to parse. Examples: oracle's sql net configuration files (at least pre v 8). Various GNU configuration files which is really lisp. Get real and keep it simple. Not everybody is a CompSci major. greetings, ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 7:42 ` Tarjei T. Jensen @ 2002-06-13 13:53 ` Georg Bauhaus 2002-06-13 14:10 ` Stephen Leake 1 sibling, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-13 13:53 UTC (permalink / raw) Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote: : Aaarrrggggghhhhhhhh!!!!!!!!! (Likewise :-) : When will people learn that config files should be readable and : understandable. Understanding starts at understanding the contents and the structure, not the syntax. That's essential. How does one capture dependencies of settings in kv pairs? E.g. the syntax of Samba configuration files is quite simple. That doesn't make Samba configuration something that can be easily understood, by CS majors or non-CS-majors. As an anylogy, it is quite easy to learn how to read Spanish or Russian. Without understanding a word of it. -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 7:42 ` Tarjei T. Jensen 2002-06-13 13:53 ` Georg Bauhaus @ 2002-06-13 14:10 ` Stephen Leake 2002-06-13 16:50 ` Warren W. Gay VE3WWG 2002-06-13 17:28 ` Tarjei Tj�stheim Jensen 1 sibling, 2 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-13 14:10 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > Stephen Leake wrote: > > However, I think a sufficiently small subset of XML is ok. I'll be > > posting a complete example Real Soon Now :). > > > Aaarrrggggghhhhhhhh!!!!!!!!! > > When will people learn that config files should be readable and > understandable. Yes, that is one of the requirements for Config_Files. You seem to be implying that XML is inherently _not_ readable, or _not_ understandable. Many people here disagree. If you have examples, or reasons, or suggestions for improvement, that would be helpful. Mere statements of dislike are not helpful. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 14:10 ` Stephen Leake @ 2002-06-13 16:50 ` Warren W. Gay VE3WWG 2002-06-13 17:31 ` Tarjei Tj�stheim Jensen 2002-06-14 16:11 ` Stephen Leake 2002-06-13 17:28 ` Tarjei Tj�stheim Jensen 1 sibling, 2 replies; 83+ messages in thread From: Warren W. Gay VE3WWG @ 2002-06-13 16:50 UTC (permalink / raw) Stephen Leake wrote: > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: >>Stephen Leake wrote: >> >>>However, I think a sufficiently small subset of XML is ok. I'll be >>>posting a complete example Real Soon Now :). >> >>Aaarrrggggghhhhhhhh!!!!!!!!! >> >>When will people learn that config files should be readable and >>understandable. > > Yes, that is one of the requirements for Config_Files. > > You seem to be implying that XML is inherently _not_ readable, or > _not_ understandable. > > Many people here disagree. If your goal is to provide a configuration file that is as simple as a .ini file, then I think any subset of XML is a poor choice. Here's one reason why: It _does_ add complexity. As Ted mentioned in an earlier post, if you had to describe to a person who barely can handle an editor over the phone (the worst kind of support position), you would have to ask many questions about whether a tag was properly closed etc. You'd have to start by describing how tags open and close for starters.. and they probably wouldn't really get it anyway. Then going beyond that to nested tags - arg! I for one, would hate to be in that sort a support role. But even ignoring support roles, it is easier to describe an ini file change, than a XML change in a document. BUT, if your _goal_ is a hierarchical structure like the Windoze registry, then I think you should be prepared to accept binary and focus on it at the API and implementation level. The way to make it user configurable, is to provide a regedit type of tool that is general enough to handle most cases. Perhaps make it type extendable that is supported by dynamic shared libraries. Furthermore, it is then possible to layer some ACL type of security on your values. I personally would like to see this registry-like data in a postgres database, with a smooth API to access/create/modify values. The disadvantage of course, is that this would require that Postgres be running on all hosts where your application goes. There is a fellow that is attempting to put all Linux configuration values into a Postgres database. I think I saw this in a Linux publication last fall. This approach will then make it easier to configure all aspects of the system from a GUI. So many have already said here: your implementation will depend upon your design goals. Warren. ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 16:50 ` Warren W. Gay VE3WWG @ 2002-06-13 17:31 ` Tarjei Tj�stheim Jensen 2002-06-14 16:11 ` Stephen Leake 1 sibling, 0 replies; 83+ messages in thread From: Tarjei Tj�stheim Jensen @ 2002-06-13 17:31 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > I for one, would hate to be in that sort a support role. But > even ignoring support roles, it is easier to describe an ini > file change, than a XML change in a document. Completely agree. > I personally would like to see this registry-like data in a > postgres database, with a smooth API to access/create/modify > values. The disadvantage of course, is that this would require > that Postgres be running on all hosts where your application > goes. There is a fellow that is attempting to put all Linux > configuration values into a Postgres database. I think I > saw this in a Linux publication last fall. This approach will > then make it easier to configure all aspects of the system > from a GUI. You can have much more than that as well. You don't need a database for each computer. And one could have VMS style name translations. That would be interesting. And now; a nice short holiday. Back on tuesday. greetings, ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 16:50 ` Warren W. Gay VE3WWG 2002-06-13 17:31 ` Tarjei Tj�stheim Jensen @ 2002-06-14 16:11 ` Stephen Leake 1 sibling, 0 replies; 83+ messages in thread From: Stephen Leake @ 2002-06-14 16:11 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > Stephen Leake wrote: > > > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > >>Stephen Leake wrote: > >> > >>>However, I think a sufficiently small subset of XML is ok. I'll be > >>>posting a complete example Real Soon Now :). > >> > >>Aaarrrggggghhhhhhhh!!!!!!!!! > >> > >>When will people learn that config files should be readable and > >>understandable. > > Yes, that is one of the requirements for Config_Files. > > You seem to be implying that XML is inherently _not_ readable, or > > _not_ understandable. > > Many people here disagree. > > > If your goal is to provide a configuration file that is as simple > as a .ini file, then I think any subset of XML is a poor choice. Not quite; see the web page: http://users.erols.com/leakstan/Stephe/Ada/Config_Files/config_files.html Your statement is close, but not quite right. For example, ini files only have one layer of hierarchy; I'm now requiring more (that seemed to be the consensus here). > Here's one reason why: > > It _does_ add complexity. As Ted mentioned in an earlier post, if > you had to describe to a person who barely can handle an editor > over the phone (the worst kind of support position), you would > have to ask many questions about whether a tag was properly closed > etc. You'd have to start by describing how tags open and close > for starters.. and they probably wouldn't really get it anyway. > Then going beyond that to nested tags - arg! Yes. Have I captured that sufficiently in my "Disadvantages of XML format " section? > I for one, would hate to be in that sort a support role. But even > ignoring support roles, it is easier to describe an ini file change, > than a XML change in a document. Ok, if we assume people are not familiar with tag syntax. Quoting special symbols is a bigger problem for me. > BUT, if your _goal_ is a hierarchical structure like the Windoze > registry, then I think you should be prepared to accept binary and > focus on it at the API and implementation level. My goal is somewhere between ini and registry, but much closer to ini. A primary requirement is editing with "simple text editors". > The way to make it user configurable, is to provide a regedit type > of tool that is general enough to handle most cases. Perhaps make it > type extendable that is supported by dynamic shared libraries. > Furthermore, it is then possible to layer some ACL type of security > on your values. Might as well just use the registry, or Gnome gconf. > I personally would like to see this registry-like data in a postgres > database, with a smooth API to access/create/modify values. The > disadvantage of course, is that this would require that Postgres be > running on all hosts where your application goes. There is a fellow > that is attempting to put all Linux configuration values into a > Postgres database. I think I saw this in a Linux publication last > fall. This approach will then make it easier to configure all > aspects of the system from a GUI. Look at the Gnome gconf stuff (on sourceforge). > So many have already said here: your implementation will depend upon > your design goals. Which is why the requirements (goals) are listed on the web page. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 14:10 ` Stephen Leake 2002-06-13 16:50 ` Warren W. Gay VE3WWG @ 2002-06-13 17:28 ` Tarjei Tj�stheim Jensen 2002-06-19 9:48 ` Preben Randhol 1 sibling, 1 reply; 83+ messages in thread From: Tarjei Tj�stheim Jensen @ 2002-06-13 17:28 UTC (permalink / raw) Stephen Leake wrote: > If you have examples, or reasons, or suggestions for improvement, that > would be helpful. If you ever get to do first line telephone support for users, you will know that anything complicated is too complicated. You will also send lots of happy thoughts to those who invented remote control for PCs. > Mere statements of dislike are not helpful. I take it you have not tried to connect a client machine to an oracle server at the time you had to edit the configuration files by hand. Oracle likes parethesises, lots of them. To a end-user those are about as useful as XML is. XML is good when you have a program talking to another program and they have lots of CPU cycles to spare. It is NOT good for human readable files. One would think that just reading one of those wonderful XML books reeinforced that impression. greetings, ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-13 17:28 ` Tarjei Tj�stheim Jensen @ 2002-06-19 9:48 ` Preben Randhol 0 siblings, 0 replies; 83+ messages in thread From: Preben Randhol @ 2002-06-19 9:48 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1360 bytes --] Tarjei Tj�stheim Jensen <tarjei@online.no> wrote on 13/06/2002 (19:32) : > Stephen Leake wrote: > > If you have examples, or reasons, or suggestions for improvement, that > > would be helpful. > > If you ever get to do first line telephone support for users, you will > know that anything complicated is too complicated. I know and I agree. I would rather see the much easier: Program.name=Glosa Program.version=0.8 etc.. than the xml suggestions. > You will also send lots of happy thoughts to those who invented remote > control for PCs. Yes or Linux. So nice to be able to maintain my father machine which is 1000km from my home and my girlfriends which is about 3000km away. When it comes to windows then aaaaaarrrggg!! ;-) > XML is good when you have a program talking to another program and they > have lots of CPU cycles to spare. It is NOT good for human readable > files. One would think that just reading one of those wonderful XML > books reeinforced that impression. Yes XML is hyped out of propotions and used inn all connections like a new miracle drug that cures any desease. > > greetings, > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada -- Preben Randhol �For me, Ada95 puts back the joy in programming.� ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 19:29 ` Ted Dennison 2002-06-05 7:18 ` Volkert Barr 2002-06-09 22:00 ` Stephen Leake @ 2002-06-10 14:45 ` Georg Bauhaus 2 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-10 14:45 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote: : If we are to stick with simple attribute-value pairs, then XML would : be major overkill. Having dealt with samba config files, # the option 'an option', dependent on foo = value, provided option bar=yes, # does bla bla bla an option = a value I really enjoy well structured configuration data. This is where a reasonably small DTD enters the scene, explaining the relations among configurable items. Being herectic for a moment, I'd say that you could even - support a config API that uses a DTD with XML as input and translates this into a program specific useful internal representation - "map" an application specific DTD to a common DTD for configurations. Lists of key:=value are flat, possibly interrupted by section headings providing a very basic name space, XML data are trees with nodes that can be individually address by - paths, - IDs - predicates. To me this looks somewhat like an asm-listing compared to a structured program. -- Georg ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-04 6:26 ` Volkert Barr 2002-06-04 12:47 ` SteveD 2002-06-04 19:29 ` Ted Dennison @ 2002-06-09 21:52 ` Stephen Leake 2002-06-10 0:02 ` Preben Randhol 2 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-09 21:52 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> writes: > Yes XML can help here, but the most projects i have seen, XML was a > complete > overkill! You really should look at the implemenation of Glib.XML. Get it from the GtkAda distribution at http://libre.act-europe.fr/GtkAda/ It's _one_ Ada package; the body file is 671 lines long. I don't think that's overkill for anything! > Don't forget, that a syntax definition the XML files is necessary Nope; we can ignore it, because we've got very simple requirements. However, if you want it for your app, you can add it. > and parsing/navigation/errorhandling is still your problem! This should all be covered by the Config Files API. Please check the draft spec when I post it to make sure I haven't missed something. > I believe, a simple Package/Key/Value Style works well for most > problems. And XML is a simple way to represent that style. > And today, XMLAda based on the GNAT Spitbol package and is not > compiler independent! But compiler independence should be an > requirement for the Configuration Packages! Certainly the API and file format should be compiler and OS independent. But any particular implementation is free to be compiler dependent. If enough people don't like that, they'll produce another implementation. It is not true that all XML implementations will be GNAT dependent! Glib.XML is not. There are many C implementations that could be imported. > If there is a consensus that XML is needed, the Spitbowl Package > must be ported! No. People who don't want to use GNAT must find another XML package. -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-09 21:52 ` Stephen Leake @ 2002-06-10 0:02 ` Preben Randhol 2002-06-10 12:42 ` Stephen Leake 0 siblings, 1 reply; 83+ messages in thread From: Preben Randhol @ 2002-06-10 0:02 UTC (permalink / raw) On Sun, 09 Jun 2002 21:52:06 GMT, Stephen Leake wrote: > Volkert Barr <barr@cs.tu-berlin.de> writes: > >> Yes XML can help here, but the most projects i have seen, XML was a >> complete >> overkill! > > You really should look at the implemenation of Glib.XML. Get it from > the GtkAda distribution at http://libre.act-europe.fr/GtkAda/ > > It's _one_ Ada package; the body file is 671 lines long. I don't think > that's overkill for anything! But it doesn't contain any verification code and does it handle attributes? Preben ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 0:02 ` Preben Randhol @ 2002-06-10 12:42 ` Stephen Leake 2002-06-10 16:21 ` Pascal Obry 0 siblings, 1 reply; 83+ messages in thread From: Stephen Leake @ 2002-06-10 12:42 UTC (permalink / raw) Preben Randhol <randhol+abuse@pvv.org> writes: > On Sun, 09 Jun 2002 21:52:06 GMT, Stephen Leake wrote: > > You really should look at the implemenation of Glib.XML. Get it from > > the GtkAda distribution at http://libre.act-europe.fr/GtkAda/ > > > > It's _one_ Ada package; the body file is 671 lines long. I don't think > > that's overkill for anything! > > But it doesn't contain any verification code True. Why is that an issue? > and does it handle attributes? Also true. Why is that an issue? -- -- Stephe ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 12:42 ` Stephen Leake @ 2002-06-10 16:21 ` Pascal Obry 2002-06-12 11:29 ` Georg Bauhaus 0 siblings, 1 reply; 83+ messages in thread From: Pascal Obry @ 2002-06-10 16:21 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> writes: > Preben Randhol <randhol+abuse@pvv.org> writes: > > > On Sun, 09 Jun 2002 21:52:06 GMT, Stephen Leake wrote: > > > You really should look at the implemenation of Glib.XML. Get it from > > > the GtkAda distribution at http://libre.act-europe.fr/GtkAda/ > > > > > > It's _one_ Ada package; the body file is 671 lines long. I don't think > > > that's overkill for anything! > > > > But it doesn't contain any verification code > > True. Why is that an issue? > > > and does it handle attributes? > > Also true. Why is that an issue? I agree with Stephen. The XML reader can do only what is needed to read the config file. We don't need an SAX or DOM compliant reader, it is the same work to read/validate all possible XML document and read a very well defined (DTD) XML document... So the integrated reader we would use for the config package is certainly in the order of 1_000 lines of code... Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: Use of XML for config files 2002-06-10 16:21 ` Pascal Obry @ 2002-06-12 11:29 ` Georg Bauhaus 0 siblings, 0 replies; 83+ messages in thread From: Georg Bauhaus @ 2002-06-12 11:29 UTC (permalink / raw) Pascal Obry <p.obry@wanadoo.fr> wrote: : The XML reader can do only what is needed to read the : config file. Indeed the ckecking can be done outside the application! If the configuration document has been validated somewhere, the program can slurp the data and do no ckecking (other than what cannot be captured by an XML validating application/editor). Done. ^ permalink raw reply [flat|nested] 83+ messages in thread
end of thread, other threads:[~2002-06-24 14:11 UTC | newest] Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-05 10:02 Use of XML for config files Grein, Christoph 2002-06-09 22:13 ` Stephen Leake 2002-06-10 1:42 ` Darren New 2002-06-10 12:46 ` Stephen Leake 2002-06-10 15:52 ` Darren New -- strict thread matches above, loose matches on Subject: below -- 2002-06-05 8:25 Grein, Christoph 2002-06-05 8:39 ` Volkert Barr 2002-06-05 9:31 ` Manuel Collado 2002-06-05 10:01 ` Volkert Barr 2002-06-05 7:33 Grein, Christoph 2002-06-05 7:59 ` Volkert Barr 2002-06-03 11:48 Mike and Lynn Card 2002-06-03 17:42 ` Pascal Obry 2002-06-04 6:26 ` Volkert Barr 2002-06-04 12:47 ` SteveD 2002-06-04 13:51 ` Volkert Barr 2002-06-04 19:29 ` Ted Dennison 2002-06-05 7:18 ` Volkert Barr 2002-06-05 10:24 ` Georg Bauhaus 2002-06-05 11:35 ` Preben Randhol 2002-06-05 14:52 ` Georg Bauhaus 2002-06-05 15:22 ` Preben Randhol 2002-06-05 19:11 ` Darren New 2002-06-06 13:38 ` Georg Bauhaus 2002-06-06 15:06 ` Darren New 2002-06-07 11:28 ` Georg Bauhaus 2002-06-07 17:10 ` Darren New 2002-06-06 6:48 ` Volkert Barr 2002-06-06 13:27 ` Georg Bauhaus 2002-06-05 14:41 ` Robert C. Leif 2002-06-09 22:00 ` Stephen Leake 2002-06-10 15:03 ` Ted Dennison 2002-06-10 18:12 ` Stephen Leake 2002-06-12 11:25 ` Georg Bauhaus 2002-06-12 15:33 ` Darren New 2002-06-12 17:53 ` Stephen Leake 2002-06-13 14:18 ` Ted Dennison 2002-06-13 16:36 ` Stephen Leake 2002-06-14 3:27 ` Ted Dennison 2002-06-14 15:54 ` Stephen Leake 2002-06-12 19:18 ` Georg Bauhaus 2002-06-13 13:53 ` Ted Dennison 2002-06-13 15:26 ` Georg Bauhaus 2002-06-13 16:39 ` Darren New 2002-06-13 17:06 ` Georg Bauhaus 2002-06-13 17:43 ` Darren New 2002-06-14 15:56 ` Georg Bauhaus 2002-06-13 17:54 ` Georg Bauhaus 2002-06-13 18:31 ` Darren New 2002-06-14 16:04 ` Stephen Leake 2002-06-14 16:48 ` Darren New 2002-06-14 17:03 ` Georg Bauhaus 2002-06-14 17:22 ` Darren New 2002-06-18 15:20 ` Georg Bauhaus 2002-06-18 15:37 ` Darren New 2002-06-18 18:20 ` Georg Bauhaus 2002-06-18 19:11 ` Stephen Leake 2002-06-18 21:47 ` Darren New 2002-06-19 11:31 ` Georg Bauhaus 2002-06-19 15:13 ` Stephen Leake 2002-06-19 21:14 ` Georg Bauhaus 2002-06-20 14:38 ` Stephen Leake 2002-06-20 16:02 ` Georg Bauhaus 2002-06-20 20:37 ` Stephen Leake 2002-06-21 16:24 ` Ted Dennison 2002-06-24 14:11 ` Stephen Leake 2002-06-19 16:43 ` Darren New 2002-06-19 20:33 ` Georg Bauhaus 2002-06-12 17:48 ` Stephen Leake 2002-06-13 7:42 ` Tarjei T. Jensen 2002-06-13 13:53 ` Georg Bauhaus 2002-06-13 14:10 ` Stephen Leake 2002-06-13 16:50 ` Warren W. Gay VE3WWG 2002-06-13 17:31 ` Tarjei Tj�stheim Jensen 2002-06-14 16:11 ` Stephen Leake 2002-06-13 17:28 ` Tarjei Tj�stheim Jensen 2002-06-19 9:48 ` Preben Randhol 2002-06-10 14:45 ` Georg Bauhaus 2002-06-09 21:52 ` Stephen Leake 2002-06-10 0:02 ` Preben Randhol 2002-06-10 12:42 ` Stephen Leake 2002-06-10 16:21 ` Pascal Obry 2002-06-12 11:29 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox