The dialogue manager is programmed by a set of if-then-else clauses [Denecke1997] each of which consists of three lists of predicates representing the condition, the positive conclusion and the negative conclusion, respectively. The predicates range over typed variables. The typed variables in the predicates are instantiated with feature structures held in the focus of the discourse, intentional models and communicative goal.
Figure 9: The rule triggering the action associated with the task descriptions.
U and S refer to the user's and the system's model of intentions, respectively.
pop and top are the usual operations on stacks. If the intention of the user is
uniquely determined (first condition) and all the
information in the discourse meets the constraints imposed by the value of
the 
feature (second condition) then the goal is evaluated
and the current intentions of system and user are removed from the stack.
The clauses can be divided into domain-specific and domain-independent clauses, the former ones governing domain-specific interaction with domain-specific databases, possibly hardware and the like, while the latter ones specify the dialogue strategy. The clauses for the dialogue strategy rely on the differences in representations contained in the discourse and the intentional states and quantifications over these. These differences are then expressed in underspecified typed feature structures as shown above. Although differences are expressed using domain-specific types from the type hierarchy, the calculation of the differences and their quantification is independent from the particular domain model.
Figure 9 shows a domain-independent clause stating that if the intention of the user has been determined uniquely and all information necessary to evaluate the goal related to the user's intention could be accumulated then the goal should be evaluated and the current representations of the intentions of the user and the system respectively should be removed from the stacks.
In addition to defining rules, the language allows for the definition of procedures, and going along with this, overloading. The evalgoal predicate typically is overloaded with some application-specific definition related to the goal. The possibility to overload predicates is one of the crucial features that allows us to specify dialogue strategies in a domain-independent fashion. The overloaded predicates specify the behavior of the system when the intention of the user has been determined and sufficient information has been accumulated to make the execution of the task possible. The specification of the domain-specific rules answers the third question of how to perform the intended tasks.
The input stemming from the parser triggers appropriate clauses to fire. If the current input is the first one for a new dialogue, all compatible task descriptions are retrieved, and an underspecified feature structure representing all of them is loaded in the model of the user's intention. The first step to do now is to disambiguate the intention if it is not unique. Since database requests and processing of semantic representations can be interleaved, information query results may additionally increase the specificity of the representations thus leading to fewer clarification questions.
The application-specific clauses together with the task model and parts of the domain model are the only instances that describe the behavior of the dialogue system, meaning that a move to a new application domain would require modification of only these instances.
The described features have been implemented in a travel information booth setting. The overall turn-around time, i.e. the time between receiving the hypothesis of the speech recognizer and producing the output of the system, is typically between one and two seconds on a 200 MHz Pentium II Linux machine. The execution time depends primarily on the number of and the operations performed on the objects returned by the database requests.