Recipe Parsing

[Radek Pazdera]

Hi,

I'm thinking about the parser implementation that would suit best to
LNST's current status (with all the changes so far) and I think I'm
finally starting to get it.

The change introduced in the new parsing approach should be, the way
the parser processes each tag. In the current implementation, tags are
processed in order that is defined by the parser. It's usually
achieved like this:


     tag1_grp = parent.getElementsByTagName("tag1")
     self._parse(tag1_grp)

     tag2_grp = parent.getElementsByTagName("tag2")
     self._parse(tag2_grp)

This is a problem for aliases and functions, because some tags could
have been processed in a wrong order or left out completely.
For instance:

<parent>
<tag1 />
<tag1 />
<tag2 />
<tag1 />
</parent>

In this case, the above code will process the last "tag1" before
processing "tag2".

In the new parsing approach, we should focus on parsing the tags in
order which is defined by the document. For example:

     for node in parent.childNodes:
         if node.nodeType != node.Element:
             raise ParsingError("Only tags allowed here")

         if node.nodeName == "tag1":
             self._parse(node)
         elif node.nodeName == "tag2":
             self._parse(node)
         else:
             raise ParsingError("%s not allowed here" % self.NodeName)


This would be achievable with keeping the current parser structure
(the parser is split into multiple objects - which makes the code
look better). We could create a base XmlParser class that would
implement some basic parsing API and also take care of the aliases,
functions and includes.

There would be a top level NetTestParser (as it is now) that would
parse the basic structure and then call NetConfigParser for configs,
NetTestCommandParser for commands etc.

Each parser will hold a reference to a "recipe" dictionary and update
it as it parses the XML. The NetConfigParser also will be able to
contact slaves through RPC and validate MAC's / device names.

This approach will allow us to make the aliases definitions local
within the parent tag. Which makes a lot of sense. Now they're global
only across the whole recipe (and even the includes).

<parent attr="{$abc}">
<define>
<alias name="abc" value="5" />
</define>
<child attr="{$abc}" />
</parent>

The first $abc would be undefined, in the current implementation on
the other hand, it would resolve to 5.

Another problem is with aliases within includes. The includes are
preprocessed even before the aliases are resolved, so currently

<tag source="{$tag_src}" />

will not resolve even in case the alias has been defined correctly. The
sequential approach would solve this as well.

Radek