Main Page Modules Class Hierarchy Compound List File List Compound Members

# Overview

XML is ideal as an alternative representation of NED. By supporting XML, NED becomes more interoperable with other systems, and it is be possible to process it with standard tools. (Note that XML is unsuitable though as the only representation of NED information because of its relatively poor readability.)

As an example, let's see a short NED code fragment and its XML representation:

     module FDDINode
         parameters:
             address : string;
         gates:
             in: net_in;
             out: net_out;
         submodules:
             MAC: FDDI_MAC
                 parameters:
                     mac_address = address;
                     promiscuous = false;
             ...
     endmodule

The XML version is a bit less readable but straightforward:

     <?xml version="1.0" ?>
     <nedfile filename="fddi.ned">
         <module name="FDDINode">
             <params>
                 <param name="address" datatype="string"/>
             </params>
             <gates>
                 <gate gatetype="in" isvector="false" name="net_in" />
                 <gate gatetype="out" isvector="false" name="net_out" />
             </gates>
             <submodules>
                 <submodule name="MAC" typename="FDDI_MAC">
                     <substparams>
                         <substparam name="mac_address" value="address"/>
                         <substparam name="promiscuous" value="false"/>
                     </substparams>
                 </submodule>
                 ...

The above XML fragment should be quite self-explanatory for those familiar with NED.

A DTD (document type descriptor) exists to describe the format of valid NED XML documents.

The NED-XML infrastructure is centered around data classes that are the in-memory representation of NED. The data structure is an object tree, where each XML element (e.g. <param name="address" datatype="string"/>) is represented by an object. The central class is NEDElement, which provides DOM-like generic methods to navigate the tree, enumerate and query attributes, etc. Each XML element has a corresponding class, subclassed from NEDElement, e.g. for the <param> element the class is called ParamNode. Specific element classes provide a stricter, more typed interface to access the data tree.

Several components build around the data classes:

- input filters build a NEDXML object tree using data from some external data source. Currently available input filters are NED parser and XML parser.
- output filters take a NEDXML object tree and transform it into some other format. Currently available output filters are NED generator, XML generator, and C++ code generator (for nedc).
- validators check that a NEDXML object tree contains valid information, that is, it conforms to the DTD and other, stricter rules. Currently implemented validators consist of several stages which can check the tree up to the level required by nedc.

An exciting output filter is still to be implemented: a network builder, which, linked with the simulation kernel and necessary simple modules, can build up a network on the fly, without having to generate C++ (plus compile and link it) first.

Based on the infrastructure, a NED compiler can be assembled from a NED parser and a C++ code generator component. GNED can utilize the NED parser and NED generator components. Both nedc and GNED will be able to import and export XML by just adding the XML parser and XML generator components. The infrastructure makes it easier to build models dynamically. For example, when building networks from data coming from a database, one might let the database query produce XML (several databases are already capable of that), then apply an XSLT transformation to convert to NED-XML if needed. Then one might apply the network builder to set up the network directly; or use the NED generator to create NED source for debugging purposes.

The central idea is to have a common data structure for representing NED, and this data stucture can act as a hub for connecting different data formats, data sources and applications.