Re: Enhanced Model for CCXML State Management

At 08:16 2006-06-23, you wrote:
>Check out, our new state
>chart langage.  It contains a "parallel" concept that could handle your
>two parallel activities.  Also, Ken Rehor and Judith Markowitz are working
>on a Speaker Identification and Verification that will include a variety
>of techniques for verifying who the caller is.  While I personally think
>that using ANI is a dumb way to identify the caller (someone else uses
>your phone and pretends to be you), the forthcoming SIV techniques could
>be used within VoiceXML and/or CCXML.


Thanks for writing.

I've read through the SCXML document, and while it handles parallel states, 
it doesn't seem to fully solve the requirements of the use case that I 
outlined. In addition, it doesn't seem to solve the problem of uncolored 
(or "untagged") events.

To recap, the use case is:

(a) the application answers the phone to say "Welcome to the Acme Call 
(b) the application uses ANI/caller ID to check the identity of the caller 
and see if the caller is authorized for use of the system.

A good solution to this problem is to create a separate process to handle 
the authorization of the caller -- send HTTP requests, wait for the far-end 
authorization to proceed, and send the results back to the main script via 
an event. The same holds true for the end of the voice prompt.

In order to transition to the next overall state, two events must arrive: 
authorization result and end-of-dialogue. SCXML's parallel states seem to 
provide a pretty decent solution. When the authorization arrives, parallel 
state A handles all necessary logic; when end-of-dialogue arrives, parallel 
event B handles necessray logic, and then A and B join to transition to the 
next major state of the overall script.

On the other hand, if I've read section G of the spec correctly, any events 
are sent to each of the parallel states for processing, but I can't tell if 
the uninterested states have to explicity dispose of irrelevant events -- 
if so that would likely introduce errors in scripts.

But the main issue is that when I'm trying to accomplish a transition on 
the condition "Event A plus Event B," the state-centric SCXML model 
requires quite a bit of code to accomplish this, which is handled 
effortlessly by Petri nets. Yes, from the spec it's theoretically more 
mainstream in SCXML than in CCXML to handle these AND-condition event-based 
transitions; at the same time, the code is still a work-around, and the 
burden lies with the programmer instead of the interpreter to manage that 
simple but very common event-logic condition. That's a consequence of the 
state-centric view.

The other issue I raised in my original email is of events that should be 
"colored" or "tagged" to arrive only at specific states. I gave the example 
of a cancel followed by error.notallowed; the error.notallowed while the 
script is in some arbitrary state, and it's difficult if not impossible to 
decide what to do about it.

I'd be delighted to learn that I'm wrong and SCXML actually addresses all 
these issues. In the meantime, I'm re-reading the SCXML specification...

Oh, and in regards to ANI: yes, I agree that ANI isn't a reliable means of 
identification, but it's often a nice first step for some services. I look 
forward to SVIC-XML for speaker verificaion, identification, and 


  Moshe Yudkowsky
  2952 W Fargo
  Chicago, IL 60645 USA

  +1 773 764 8727

Received on Friday, 23 June 2006 15:04:40 UTC