-The XML checking is done based on the [simgrid.dtd](http://simgrid.gforge.inria.fr/simgrid/simgrid.dtd) Document Type
-Definition (DTD) file.
-
-If you read the DTD, you should notice the following:
-\li The platform tag has a version attribute. The current version is <b>4</b>. This attribute might be used in the
- provide backward compatibility.
-\li The DTD contains definitions for both the platform description and deployment files used by SimGrid.
-
-\section pf_netzones Defining a netzone
-
-Here is a simplistic example, describing a netzone using the Full
-routing. Other supported values for the routing attribute can be
-found below, Section \ref pf_raf.
-
-
-\verbatim
-<AS id="netzone0" routing="Full">
-\endverbatim
-
-There is also the ``<route>`` tag; this tag takes two attributes,
-``src`` (source) and ``dst`` (destination). Both source and
-destination must be valid identifiers for routers (these will be
-introduced later). Contained by the ``<route>`` are network links;
-these links must be used in order to communicate from the source to
-the destination specified in the tag. Hence, a route merely describes
-how to reach a router from another router.
-
-\remark
- More information and (code-)examples can be found in Section \ref pf_rm.
-
-A netzone can also contain itself one or more netzone; this allows you to model
-the hierarchy of your platform.
-
-### Within each AS, the following types of resources exist:
-
-%Resource | Documented in Section | Description
---------------- | --------------------- | -----------
-AS | | Every Autonomous System (AS) may contain one or more AS.
-host | \ref pf_host | This entity carries out the actual computation. For this reason, it contains processors (with potentially multiple cores).
-router | \ref pf_router | In SimGrid, routers are used to provide helpful information to routing algorithms. Routers may also act as gateways, connecting several autonomous systems with each other.
-link | \ref pf_link | In SimGrid, (network)links define a connection between two or potentially even more resources. Every link has a bandwidth and a latency and may potentially experience congestion.
-cluster | \ref pf_cluster | In SimGrid, clusters were introduced to model large and homogenous environments. They are not really a resource by themselves - technically, they are only a shortcut, as they will internally set up all the hosts, network and routing for you, i.e., using this resource, one can easily setup thousands of hosts and links in a few lines of code. Each cluster is itself an AS.
-
-As it is desirable to interconnect these resources, a routing has to
-be defined. The AS is supposed to be Autonomous, hence this has to be
-done at the AS level. The AS handles two different types of entities
-(<b>host/router</b> and <b>AS</b>). However, the user is responsible
-to define routes between those resources, otherwise entities will be
-unconnected and therefore unreachable from other entities. Although
-several routing algorithms are built into SimGrid (see \ref pf_rm),
-you might encounter a case where you want to define routes manually
-(for instance, due to specific requirements of your platform).
-
-There are three tags to use:
-\li <b>ASroute</b>: to define routes between two <b>AS</b>
-\li <b>route</b>: to define routes between two <b>host/router</b>
-\li <b>bypassRoute</b>: to define routes between two <b>AS</b> that
- will bypass default routing (as specified by the ``routing`` attribute
- supplied to ``<AS>``, see above).
-
-Here is an illustration of these concepts:
-
-![An illustration of an AS hierarchy. Here, AS1 contains 5 other ASes who in turn may contain other ASes as well.](AS_hierarchy.png)
- Circles represent processing units and squares represent network routers. Bold
- lines represent communication links. AS2 models the core of a national
- network interconnecting a small flat cluster (AS4) and a larger
- hierarchical cluster (AS5), a subset of a LAN (AS6), and a set of peers
- scattered around the world (AS7).
-
-\section pf_pftags Resource description
-
-\subsection pf_As Platform: The <AS> tag
-
-The concept of an AS was already outlined above (Section \ref pf_basics);
-recall that the AS is so important because it groups other resources (such
-as routers/hosts) together (in fact, these resources must be contained by
-an AS).
-
-Available attributes :
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | String | The identifier of an AS; facilitates referring to this AS. ID must be unique.
-routing | yes | Full\| Floyd\| Dijkstra\| DijkstraCache\| None\| Vivaldi\| Cluster | See Section \ref pf_rm for details.
-
-
-<b>Example:</b>
-\code
-<AS id="AS0" routing="Full">
- <host id="host1" speed="1000000000"/>
- <host id="host2" speed="1000000000"/>
- <link id="link1" bandwidth="125000000" latency="0.000100"/>
- <route src="host1" dst="host2"><link_ctn id="link1"/></route>
-</AS>
-\endcode
-
-In this example, AS0 contains two hosts (host1 and host2). The route
-between the hosts goes through link1.
-
-\subsection pf_Cr Computing resources: hosts, clusters and peers.
-
-\subsubsection pf_host <host/>
-
-A <b>host</b> represents a computer/node card. Every host is able to execute
-code and it can send and receive data to/from other hosts. Most importantly,
-a host can contain more than 1 core.
-
-### Attributes: ###
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | String | The identifier of the host. facilitates referring to this AS.
-speed | yes | double (must be > 0.0) | Computational power of every core of this host in FLOPS. Must be larger than 0.0.
-core | no | int (Default: 1) | The number of cores of this host. If more than one core is specified, the "speed" parameter refers to every core, i.e., the total computational power is no_of_cores*speed.<br /> If 6 cores are specified, up to 6 tasks can be executed without sharing the computational power; if more than 6 tasks are executed, computational power will be shared among these tasks. <br /> <b>Warning:</b> Although functional, this model was never scientifically assessed.
-availability_file| no | string | (Relative or absolute) filename to use as input; must contain availability traces for this host. The syntax of this file is defined below. <br /> <b>Note:</b> The filename must be specified with your system's format.
-state_file | no | string | Same mechanism as availability_file.<br /> <b>Note:</b> The filename must be specified with your system's format.
-coordinates | no | string | Must be provided when choosing the Vivaldi, coordinate-based routing model for the AS the host belongs to. More details can be found in the Section \ref pf_P2P_tags.
-pstate | no | double (Default: 0.0) | FIXME: Not yet documented.
-
-### Possible children: ###
-
-Tag name | Description | Documentation
------------- | ----------- | -------------
-\<mount/\> | Defines mounting points between some storage resource and the host. | \ref pf_storage_entity_mount
-\<prop/\> | The prop tag allows you to define additional information on this host following the attribute/value schema. You may want to use it to give information to the tool you use for rendering your simulation, for example. | N/A
-
-### Example ###
-
-\verbatim
- <host id="host1" speed="1000000000"/>
- <host id="host2" speed="1000000000">
- <prop id="color" value="blue"/>
- <prop id="rendershape" value="square"/>
- </host>
-\endverbatim
-
-
-\anchor pf_host_dynamism
-### Expressing dynamism ###
-
-SimGrid provides mechanisms to change a hosts' availability over
-time, using the ``availability_file`` attribute to the ``\<host\>`` tag
-and a separate text file whose syntax is exemplified below.
-
-#### Adding a trace file ####
-
-\verbatim
-<platform version="4">
- <host id="bob" speed="500Gf" availability_file="bob.trace" />
-</platform>
-\endverbatim
-
-#### Example of "bob.trace" file ####
-
-~~~~~~~~~~~~~~{.py}
-PERIODICITY 1.0
- 0.0 1.0
- 11.0 0.5
- 20.0 0.8
-~~~~~~~~~~~~~~
-
-Let us begin to explain this example by looking at line 2. (Line 1 will become clear soon).
-The first column describes points in time, in this case, time 0. The second column
-describes the relative amount of power this host is able to deliver (relative
-to the maximum performance specified in the ``\<host\>`` tag). (Clearly, the
-second column needs to contain values that are not smaller than 0 and not larger than 1).
-In this example, our host will deliver 500 Mflop/s at time 0, as 500 Mflop/s is the
-maximum performance of this host. At time 11.0, it will
-deliver half of its maximum performance, i.e., 250 Mflop/s until time 20.0 when it will
-will start delivering 80\% of its power. In this example, this amounts to 400 Mflop/s.
-
-Since the periodicity in line 1 was set to be 1.0, i.e., 1 timestep, this host will
-continue to provide 500 Mflop/s from time 21. From time 32 it will provide 250 MFlop/s and so on.
-
-### Changing initial state ###
-
-It is also possible to specify whether the host is up or down by setting the
-``state`` attribute to either <b>ON</b> (default value) or <b>OFF</b>.
-
-#### Example: Expliciting the default value "ON" ####
-
-\verbatim
-<platform version="4">
- <host id="bob" speed="500Gf" state="ON" />
-</platform>
-\endverbatim
-
-If you want this host to be unavailable, simply substitute ON with OFF.
-
-\anchor pf_host_churn
-### Expressing churn ###
-
-To express the fact that a host can change state over time (as in P2P
-systems, for instance), it is possible to use a file describing the time
-at which the host is turned on or off. An example of the content
-of such a file is presented below.
-
-#### Adding a state file ####
-
-\verbatim
-<platform version="4">
- <host id="bob" power="500Gf" state_file="bob.fail" />
-</platform>
-\endverbatim
-
-#### Example of "bob.fail" file ####
-
-~~~{.py}
- PERIODICITY 10.0
- 1.0 0
- 2.0 1
-~~~
-
-A zero value means <b>down</b> (i.e., OFF) while a positive one means <b>up and
- running</b> (i.e., ON). From time 0.0 to time 1.0, the host is on as usual. At time 1.0, it is
-turned off and at time 2.0, it is turned on again until time 12 (2 plus the
-periodicity 10). It will be turned off again at time 13.0 until time 23.0, and
-so on.
-
-
-\subsubsection pf_cluster <cluster>