The SiAM dialogue model

Shukla and Schmidt (2006) start their book with the following sentences:

“Windows Workflow Foundation (WF) is a general-purpose programming framework for creating reactive programs that act in response to stimulus from external entities. The basic characteristics of reactive programs is that they pause during their execution, for unknown amounts of time, awaiting input. . . . The focal point of the WF programming model is the concept of an activity-a program statement in a WF program. An activity’s execu- tion is inherently resumable and unfolds in an episodic manner, pausing and resuming according to the activity’s interactions with external entities.”

It is quite evident that this concept perfectly fits to the design of dialogue interactions. Normally, a multimodal dialogue system in a Cyber-physical Environment (CPE) is a reactive program, either reacting to the external stimuli of a user input or an event in the environment. Consequently, during an interaction, pauses with an unknown amount of time occur, for example, in an instrumented environment that automatically reacts to specific sensor events. Here, most of the time the system runs in idle and awaits events. There can also be periods of time while a user is not interacting with the system or has to decide about an appropriate answer. So current activities must be interruptible and resumable during an interaction between user and system.

Because of these arguments and the idea of creating an easy-to-use dialogue modelling approach, we decided to adopt concepts from the WF into our modelling language. This mainly concerns the main sequence control elements. Figure 6.2 depicts a diagram of the main concepts that represent these control elements in the model for dialogue definition in SiAM-dp:

Dialogue - This concept represents the description of the whole dialogue. It con- tains one Node which is the parent node for the complete workflow description. Node - Abstract class for all control elements of the dialogue model. It is derived from the AbstractState concept which specifies a variable scope for the node. Variable - A variable is described by the type of an entity and the name to which the entity is associated. When initialised, the variable can receive a default value.

6.1 Dialogue Specification Model 127

ExecutabeContentNode - Contains executable content which lets the engine per- form primitive actions. It allows one to modify variables, send events to other modules, raise messages, call scripts, or write logging messages (see 6.1.3).

Sequence - A sequence contains other nodes that are sequentially executed. Decision - Enters the node in the then-slot if the given JEXL-condition (see Sec- tion 4.3.4) is true, otherwise the node in the else-slot is entered.

While - Repeatedly enters the node in the body -slot while the given JEXL-condition is true.

DoWhile - Enters the node in the body -slot once and then continuously while the given JEXL-condition is true.

WaitForEvent - Pauses the workflow execution until the defined event is fired and the given JEXL-condition is true.

Furthermore, it is possible to define more complex workflows with the StateChart con- cept. This node allows one to define a complete statechart that is executed when this node is reached. A statechart provides all the advantages introduced in the previous section 6.1.1, thus allowing one to define concurrent processes and global reactions to certain user events. The statechart concepts are adapted from the SCXML model and thus its complete potential is provided. The statechart concepts of the dialogue model are depicted in Figure 6.3.

Abstract State - Abstract parent concept for all states that primarily defines the variable scope of the state.

State - The base concept for the representation of a state. With the onEntry and

Figure 6.3 – Overview of the statechart concepts in the dialogue model

onExit slots it allows one to specify the actions that are executed when the state is entered or left, respectively. A state is derived from the concepts SourceState and TargetState and thus can be source or target content of a Transition.

Transition - Describes the transitions between states. A CondEvents can be assigned to a transition that specifies the trigger of the transition. The onTrigger slot may contain executable content, which is executed when the transition is taken. AbstractCompositeState - The abstract concept represents all states that are composite states and hence can contain one or more states as content in the states slot. An AbstractCompositeState may also define a history state for state configu- ration recording.

HistoryState - A pseudo-state that records the last visited state inside a com- posite state before it is left. It allows one to return to a previously interrupted workflow. The type of a history state can be shallow or deep. A shallow history state remembers the last visited state on the same level of hierarchy. The deep his- tory state remembers the last visited atomic descendant, which may be at a deeper level. A history state can be the target of a transition.

CompositeState - A composite state is a state that contains one or more sub states. The initial state that becomes active if the composite state is entered is defined with the slot initialState.

6.1 Dialogue Specification Model 129

StateChart - A special version of the CompositeState concept, which describes the root element of a statechart. It is also derived from the concept Node (see Figure 6.2).

ParallelState - A parallel state executes all its child states in parallel. Thus, when a parallel state is active, all of its child states are active. This also means that each event is handled in each child state separately. Thus, one event can trigger distinct transitions inside the parallel child states.

CondEvent - This concept describes the trigger for a transition. It contains three slots. The slot event specifies the name of the event and corresponds to the event name in the SCXML standard. If the trigger should react to input events from the SiAM-dp event manager, the event name must be InputEvent. In this case it is possible to set an additional event filter by defining a pattern in the pattern slot. Additionally, a trigger condition can be given with a JEXL-expression in the condition slot. The CondEvent concept is also used for defining an event in the WaitForEvent concept.

ExecutableContent - Is an abstract concept that represents all actions from the dialogue that can be performed. An executable content can be content of an Ex- ecutableContentNode or occur inside the onEntry and onEntry slots of a state or inside a transition in the slot onTrigger. Figure 6.4 gives an overview of the concrete concepts.

If - Allows the conditional execution of executable elements.

Assign - Changes the value of a variable in the variable scope. The to-slot defines the variable and the expression-slot contains a JEXL-expression for the value that is assigned to the variable.

Delay - Delays the state machine for the given amount of time.

Raise - Raises an internal event in the SCXML session. The identifier in the event slot is the event name on which a trigger can react.

Log - Writes a logging or debug message with the given label and expression. Send - Sends an OutputMessage to the SiAM-dp event manager and thus enables the dialogue manager to communicate with the environment.

Since every control element is an abstract state and every statechart is a control element, it is possible to mix statecharts and control elements. If a control element is used as a state in a statechart, the instructions of the control element are initially processed when the state is entered.

In practice, the dialogue model is converted to pure SCXML by the dialogue manager component (Section 7.3) before it is provided to the Apache Commons SCXML engine.

Figure 6.4 – Overview of the executable contents in the dialogue model