Changes between Version 4 and Version 5 of ExDescLang

Timestamp:

Oct 11, 2010 12:06:11 PM (14 years ago)

Author:

sunshine

Comment:

--

ExDescLang

@@ -21 +21 @@
 We may end up with a single language or a set of related languages. Here is what we need to express:
 
-  1. Topologies - both at the level of individual nodes or groups of nodes. In fact we should be expressing a ''logical'' topology of the experiment where there are '''objects''' that do something in the experiment - generate traffic, change state, hold data, whatever. Whether these objects are individually generated or generated as a group of entities, whether they are physical nodes or virtual, etc. does not matter. The expressiveness should be such that the actual implementation of objects and the cardinality of each object is orthogonal to the topology description. We should however be able to give hints such as "these objects are in the same network or on same physical node or object A resides on object B". 
-  2. Timeline of events - we need to express the ordering of actions that some objects will take in the experiment, their duration, repetition and concurrency. We also need to express state transitions in objects. In some domains this is called a ''workflow''. It could be pre-created in the experiment design stage or it could be generated manually during the experiment (mined from events that happen as user takes manual actions) or a mix of those. 
+  1. Logical topologies - both at the level of individual nodes or groups of nodes. We are expressing a ''logical'' topology of the experiment where there are '''objects''' that do something in the experiment - generate traffic, change state, hold data, whatever. Whether these objects are individually generated or generated as a group of entities, whether they are physical nodes or virtual, etc. does not matter. The expressiveness should be such that the actual implementation of objects and the cardinality of each object is orthogonal to the topology description. We should however be able to give hints such as "these objects are in the same network or on same physical node or object A resides on object B". These hints are called '''constraints'''.
+  2. Timeline of events - we need to express the ordering of actions that some objects will take in the experiment, their duration, repetition and concurrency. We also need to express state transitions in objects. In some domains this is called a ''workflow''. It could be pre-created in the experiment design stage or it could be generated manually during the experiment (mined from events that happen as user takes manual actions) or a mix of those. Each experiment class must have some default workflow that user can manipulate during experiment design.
   3. Invariants - we need to express what MUST happen in the experiment for it to be valid. Valid here means "for it to belong to a class of experiments whose metadescription we used" plus any other conditions that user wants to impose. There are two types of invariants:
      a. those that deal with objects and their states ("cache must be poisoned")
      b. those that deal with events and their features ("traffic must flow from A to B for 5 minutes at 100Mbps")
+
+'''Note that intentionally this is all pretty high-level and is orthogonal to any generator used to generate topologies, traffic, etc.''' There must be a mapping process that selects eligible generators for each dimension and takes their output and maps objects and events to it. More about this mapping process later.
+
+===