State Chart XML
One of the new asprects of VoiceXML 3.0 is the drive towards a Data-Flow-Presentation (DFP) architecture. For those of you familiar with web programming it's going to remind you of model-view-controller. The model is your data, the controller is the flow, and finally, the presentation is the view. Hardly very original so far. The main novelty is bringing in SCXML to handle the call-flow (you can check out the W3C presentation here).
Each dialog element is considered a state. There can be superstates, which contain two or more states. There are events, transitions and conditions to determine the flow between the states. Mostly applications are already implicitly state orientated - I've covered this in dialog states. I presume the aim of SCXML is to standardise this, and similarly to UML allow the design to be a first step in the actual implementation.
In effect SCXML removes the decision about the next step in the flow from the VoiceXML page. No more <goto>s, but plenty of <submit>s to the SCXML controller. After every transaction or event, the call returns to the server and the state controller determines the next state in the flow. So rather than having a element which determines what the next state is based on the caller's input, you would send the input to the state controller and it would determine what the next state is. This allows the call-flow to be specified, implemented and maintained independently of the actual user interface.
One of the benefits of SCXML is that it also allows the definition of parallel processes. This is not of great interest for voice applications which are sequential. However, it is of interest for multimodal applications which allow information to be entered using different interfaces - i.e. parallel processes.
If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums
|