[olsr-dev] New config file format
Sun Oct 10 14:42:39 CEST 2004
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
> For parsing I think I will include code from the expat(expat.sf.net)
Hmm, is the expat-lib too large (for inclusion on LinkSys-en) to be
> 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"
PUBLIC "-//OLSR.ORG//DTD olsrd.conf XML V1.0//EN"
<!ELEMENT olsrd-config (hna4, hna6, plugins)>
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>
net CDATA #REQUIRED
prefix-len CDATA #REQUIRED
<!ELEMENT plugins (plugin)*>
<!ELEMENT plugin EMPTY>
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 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
: 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
More information about the Olsr-dev