the parser; it still spits out the simplistic xml stuff and xmlconvert
still reads that):

* When generating an XML representation of an experiment, I read the
  virtual tables and build a *flat* data structure.

	{"settings" => {pid:testbed, eid:foobar ....}.
	 "nodes"    => [ {vname:nodeA, osid:RHL-STD ... },  ],
	 "lans"     => [ {vname:link0, member:nodeA ... },  ],
         ...

  So, nodes is a list of node hash tables, lans is a list of hash tables,
  etc. All of the other virt_tables are represented as well.  You can find
  everything you want as long as you the names of the fields!

* Once I have the above data structure, I use the XML-RPC lib to turn it
  into an XML document, and spit out the resulting XML string (a very long
  string!) Note that XML-RPC has its own format that allows you to convert
  data structures into XML and back; thats how you issue an RPC from your
  python client to a perl server.

* Our python XMLRPC server basically uses xmlconvert as a backend so it can
  ship the above data structure back to client. We could also allow the
  client to ship the data structure back, and have xmlconvert upload the
  changes back to the DB.

  The reason for doing it in xmlconvert as a backend is so that this XML
  stuff is in just one place; whoever reads/writes this stuff has to know a
  lot of internal detail about an experiment (like what things should not
  be exported and what things we should not allow to be imported). I prefer
  to keep that all in one place since its easy to pass XML strings around
  (as long as everyone is talking the same dialect).

Future work is to pick an XML representation that is not tied to
XML-RPC. Ideally, we want to take a data structure in Perl, spit out
the XML tree (with a DTD) and be able to reconstitute that in another
program, using the XML Parser library (based on expat, which is common
to Perl, Python, C).