Re: Enhanced Model for CCXML State Management

At 10:04 AM -0500 6/23/06, Moshe Yudkowsky wrote:
>At 08:16 2006-06-23, you wrote:
>>Moshe,
>>
>>Check out http://www.w3.org/TR/2006/WD-scxml-20060124/, 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.
>
>Jim,
>
>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 System."
>(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.

Some previous discussion related to this idea has revolved around

.. better identification for events (not blocking any states from seeing them)
http://lists.w3.org/Archives/Public/www-voice/2006JanMar/thread.html#msg98
http://lists.w3.org/Archives/Public/www-voice/2006AprJun/thread.html#msg2

.. spawning states that are waiting for a callback from an 
asynchronous external service
http://lists.w3.org/Archives/Public/www-voice/2006AprJun/thread.html#msg4

At least in the desktop world, we have situations where Assistive
Technologies post listeners for events that the author didn't
anticipate. So I would think twice about saying that certain events
are _only_ seen by states known to the event. But if the event is
identified uniquely to the particular state transition, or if the
state ID for a spawned state takes on the same uniquifying function,
there would be no confusion as to who owns, should handle, and can
cancel each event (sorry for the loose language).

Al

>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 verification, 
>identification, and classification.

>
>Regards,
>  Moshe
>
>
>--
>  Moshe Yudkowsky
>  Disaggregate
>  2952 W Fargo
>  Chicago, IL 60645 USA
>
>  Work: www.Disaggregate.com
>  Book: www.PebbleAndAvalanche.com
>
>  speech@pobox.com
>  +1 773 764 8727

Received on Friday, 23 June 2006 16:38:54 UTC