[olsr-dev] New config file format

[Bernd Petrovitsch]

On Sun, 2004-10-10 at 14:12, Andreas Tønnesen wrote:
> I have planned to rewrite the config file parser/format for olsrd for 
> some time. A new format should include the possibility to set parameters 
>   like emission intervals per network interface.
> I think I will go for a solution using XML. This should give a lot of 
> flexibility - as an example it should be a lot easier writing 
> applications that parses and changes the config file since all elements 
> should contain a textual description.

Uuuugh, what does one do if that description is not understandable or
completely missing?

> For parsing I think I will include code from the expat(expat.sf.net) 
> project.

Hmm, is the expat-lib too large (for inclusion on LinkSys-en) to be
used?

> However, I am not very much into XML and its design principals. I have 
> included a preliminary config file and would appreciate feedback on 
> things that could be done better.

First I propose you write a DTD with the explanations and descriptions
in parallel to an real config file - I realy don't think it makes any
sense to have a <description> tag in the config file.
As for the "tag vs. attribute" question: I prefer attributes if e.g. the
number of legal values is fixed (e.g. en Enum) since one can enumerate
them in the DTD or a variable takes a simple value (e.g. in int).
Using a tag make more sense to group elements and to allow free form
text which usually has no structure (and BTW every XML parser is free to
deliver the contents of an element in several text-nodes).

So reverse engineering your example may lead to (untested and checked):
----  snip  ----
<!--
    OLSRD configuration DTD V1.0

    Please use the following formal public identifier to identify it:

    "-//OLSR.ORG//DTD olsrd.conf XML V1.0//EN"

    For example:

    <!DOCTYPE article
              PUBLIC "-//OLSR.ORG//DTD olsrd.conf XML V1.0//EN"
     "http://www.olsr.org/dtd/olsr.conf-1.0.dtd"
     [...]>
-->

<!ELEMENT olsrd-config     (hna4, hna6, plugins)>
<!ATTLIST olsrd-config
                 debuglevel (0|1|2|3|4|5|6|7|8|9) #IMPLIED  "0"
                 ipversion  (4|6)                 #REQUIRED
                 pollrate   CDATA                 #IMPLIED  "auto"
                 halt-on-no-ifs (yes|no)          #IMPLIED  "yes"
>

<!ELEMENT hna4             (entry*)>
<!ELEMENT hna6             (entry*)>

<!ELEMENT entry            EMTPY>
<!ATTLIST entry
                 net        CDATA                #REQUIRED
                 prefix-len CDATA                #REQUIRED
>

<!ELEMENT plugins          (plugin)*>
<!ELEMENT plugin           EMPTY>
<!ATTLIST plugin
                 name       CDATA                #REQUIRED
>
----  snip  ----
... and so on.
The desgin criteria was:
- make an attribute of single values in the next "upper" element.
- make container elements (hna4, hna6, plugins) for similar elements
- make type specific elements (the <entry> breaks this rule somewhat
  since it is used in two different elements. This has the advantage
  of one element for the same syntax (alas it is not possible to specify
  more in a DTD - only in xml-schema which is unknown by me) vs. you
  have to know the contents of that element in the parser (and in a SAX
  parser like expat this needs a little extra work on the programmers
  side. If where to choose[0] I would call the container elements hna4s
  and hna6s and the <entry> hna4 and hna6 respectively. These entries
  will not be significantly different, so one could actually cal them
  "hna").

	Bernd

[0]: Well I don't think I would choose XML for such daemons as config
     language but this is another question.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services