Browse Source

More info on process enactment

Yentl Van Tendeloo 3 years ago
parent
commit
367118feef
1 changed files with 2 additions and 1 deletions
  1. 2 1
      doc/process_enactment.rst

+ 2 - 1
doc/process_enactment.rst

@@ -23,7 +23,7 @@ When executing a process model, models are processed and produced, and when a bi
 For example, in this case we bind the model called *pn* to the model at location *models/my_pn*.
 In the process, every occurence of *pn* is therefore processed at that location, both for input models (e.g., when chosing the Petri net to operate on) and output models (e.g., when this is the result).
 It is not necessary to define such a mapping, as it is perfectly possible that all models are created inside the process and are intended to stay in there.
-For example, in the power window case study, all DSMs are created during the process and we are only interested in the verification result, meaning that no models ``escape`` the process.
+For example, in the power window case study, all DSMs are created during the process and we are only interested in the verification result, meaning that no models "escape" the process.
 If we were to retain the DSMs, for example to push them into another process later on, we could bind all these models to an actual location in the Modelverse.
 
 The third parameter is a dictionary of callbacks.
@@ -44,3 +44,4 @@ The call then becomes::
 
 When the process executes *refine_petrinet*, the callback function is executed, and the manual operation is terminated when the function terminates.
 Other types of operation, such as *model transformations* and *action language* can also have a callback function, but this is usually less important to end users and is therefore not elaborated on here.
+In any case, their callbacks, mentioned later, can just as well be passed to process execute.