Changes between Version 21 and Version 22 of CurrentlyProposedLanguage

Timestamp:

Nov 8, 2010 9:32:01 AM (14 years ago)

Author:

sunshine

Comment:

--

CurrentlyProposedLanguage

@@ -61 +61 @@
  * Object aliases if needed: an object in a given state or whose variable(s) have some given value(s) can be assigned an alias for easier human manipulation such as a Vulnerable node that is in infected state is called Infected node.
  * Cardinality of objects using the notation specified above
- * Topological relationships between objects: one example is '''collocated''' function. Users can define other relationship functions such as A and B being on the same subnet, A being a leaf node, etc. All function definitions reside in the domain knowledge base.
+ * Topological relationships between objects: one example is '''collocated''' function. Users can define other relationship functions such as A and B being on the same subnet, A being a leaf node, etc. All function definitions reside in the domain library.
 
 || '''Meaning''' ||     '''Operator and example''' ||
@@ -87 +87 @@
 Some events may lead to transitions between states, others occur but don’t change object state. Each event has the type, the origin and one or more destinations. These are specified within curly brackets. Event names start with e followed by a number. Each event may have multiple parameters. Example of an event definition:
 
-{{{e1 := {type = TYPE, origin = object, destination = object, …}}}}
+{{{e1 := {type = TYPE, origin = object, destination = {object}, {par_i=val_i}}}}}}
 
-We should have a notion of events matching each other, like a reply matches a request. To support this there's a function '''match(event1, event2)''' which is defined in the domain knowledge base for each request/reply pair. In the timeline of events part of a meta-description if we want a reply to match a request we must explicitly say so using '''such that''' operator or have a condition on reply matching the request to proceed with the rest of the events in the sequence.
+We should have a notion of events matching each other, like a reply matches a request. To support this there's a function '''match(event1, event2)''' which is defined in the domain library for each request/reply pair. To do this properly, the definition of
+event TYPE t1 and the event match relation t1-rel should be bound
+together when they are defined. In the timeline of events part of a meta-description if we want a reply to match a request we must explicitly say so using '''such that''' operator or have a condition on reply matching the request to proceed with the rest of the events in the sequence.
 
 = Meta-descriptions =