Re: Use of XML for config files

Re: Use of XML for config files

[Grein, Christoph]

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>

Re: Use of XML for config files

[Volkert Barr]

"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>

Re: Use of XML for config files

[Manuel Collado]

"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

Re: Use of XML for config files

[Volkert Barr]

> 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

Re: Use of XML for config files

[Grein, Christoph]

> 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.

Re: Use of XML for config files

[Stephen Leake]

"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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Grein, Christoph]

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>

Re: Use of XML for config files

[Volkert Barr]

> 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

Use of XML for config files

[Mike and Lynn Card]

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

Re: Use of XML for config files

[Pascal Obry]

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

Re: Use of XML for config files

[Volkert Barr]

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

Re: Use of XML for config files

[SteveD]

"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

Re: Use of XML for config files

[Volkert Barr]

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

Re: Use of XML for config files

[Ted Dennison]

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

Re: Use of XML for config files

[Volkert Barr]

> 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

Re: Use of XML for config files

[Georg Bauhaus]

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>

Re: Use of XML for config files

[Preben Randhol]

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>

Re: Use of XML for config files

[Georg Bauhaus]

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
---

Re: Use of XML for config files

[Preben Randhol]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Volkert Barr]

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

Re: Use of XML for config files

[Georg Bauhaus]

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>
: 

RE: Use of XML for config files

[Robert C. Leif]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Ted Dennison]

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.

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Ted Dennison]

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)

Re: Use of XML for config files

[Stephen Leake]

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 &amp; 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

Re: Use of XML for config files

[Ted Dennison]

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.... :-)

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Georg Bauhaus]

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.

Re: Use of XML for config files

[Ted Dennison]

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)

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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, ...

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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.

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Ted Dennison]

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.

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Darren New]

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.

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Tarjei T. Jensen]

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,

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

"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

Re: Use of XML for config files

[Warren W. Gay VE3WWG]

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.

Re: Use of XML for config files

[Tarjei Tj�stheim Jensen]

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,

Re: Use of XML for config files

[Stephen Leake]

"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

Re: Use of XML for config files

[Tarjei Tj�stheim Jensen]

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,

Re: Use of XML for config files

[Preben Randhol]

[-- 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.�

Re: Use of XML for config files

[Georg Bauhaus]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Preben Randhol]

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

Re: Use of XML for config files

[Stephen Leake]

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

Re: Use of XML for config files

[Pascal Obry]

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

Re: Use of XML for config files

[Georg Bauhaus]

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.