Inspired by Harel's Statecharts [Ha87], the Dialog Flow Notation represents the dialog flow within an application as a directed graph of states connected by transitions. The notation refers to the transitions as events since in the implementation, states cannot specify which state shall become active next - as explained above, the dialog controller decides which transition to follow upon receipt of an event generated by a state. The notation refers to the states as dialog elements, discerning four types with different semantics: Dialog masks are hypertext pages generated by the server and rendered by the client, while actions are operations performed by the application logic on the server. Note that dialog graphs constructed out of these atomic elements do not need to be bipartite, since applications might want to display multiple masks without intermittent application logic operations, or perform a series of operations without displaying pages.

Dialog graphs can be encapsulated in dialog modules and dialog containers, which can be part of greater dialog graphs themselves. When these compound elements receive events from the exterior dialog graphs that they are integrated in, their interior dialog graph is executed, thereby realizing the key concept of nested dialogs. When the interior dialog graph of a dialog module terminates, it generates a terminal event that continues the traversal of the module's exterior dialog graph. Figure 3 illustrates these concepts by example:

Figure 3: Example of interior and exterior dialog graphs of a User Authorization dialog module

Here, the framework activates the User Authorization module (left) when the Forum Home or Shop Home mask (right) generate the enter event. Traversal of its interior dialog graph begins at the initial event, which leads to the check login status action that determines if the user is already logged in and generates a corresponding event. Assuming the Login mask features submit, register and cancel buttons, it can generate the respective events which either lead to an action checking the entered credentials, initiate traversal of the create new account module on yet another nesting level, or terminate traversal of the interior dialog graph, generating a cancelled terminal event in the exterior dialog graph (marked by an X) which leads back to the respective Home mask. If the credentials entered into the Login mask were correct, the user is marked as logged in, and a final action determines which access rights are associated with his account (Note that by splitting the application logic into these relatively fine-grained operations instead of implementing them all in one action, the module can react flexibly to different situations, like bypassing the credential check when the user is already logged in or just created an account). Depending on the user's rights, the module finally terminates generating either an is user or an is admin terminal event. According to this event, the framework activates the Forum Lobby or Forum Administration dialog container (if the module was called in the Forum container), or the Product Catalog or Shop Administration container (if the module was called in the Shop container). The demonstrated reuse of the User Authorization module in different exterior dialog graphs is only possible because the module does not specify the following element itself, but leaves that decision to the Dialog Controller which knows the specification of the exterior graph that the module is nested in. The same event generated by the same dialog element can therefore lead to different elements in different contexts.

The above-mentioned containers differ from modules in that their interior dialog graphs do not terminate by themselves. Containers are intended for encapsulating sub-applications with a "closed" dialog graph lacking a natural exit point. Traversal of their interior dialog graph (including traversal of all their currently nested compounds) can only be aborted by the framework if another container shall be activated on the same nesting level. In order to abort compounds in a controlled way, a special abort dialog graph can be specified for each of them, which might for example ask the user if he really wants to abort (also giving him a chance to resume the original dialog graph where he left off), or if he wants to save any unsaved data before aborting.

< 2. The Dialog Control Framework | 4. Conclusion >