Overview

XML is ideal as an alternative representation of NED. More...

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 ParamElement. Specific element classes provide a stricter, more typed interface to access the data tree.

Several components build around the data classes:

An exciting "output filter", network builder is implemented as an optional part of the simulation library. Network builder can set up a simulation model on the fly, provided that all simple modules are present in the executable.

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.

Generated on Tue Dec 2 11:16:31 2014 for OMNeT++ NEDXML by  doxygen 1.6.3