Re: [Communicator-user] Communicator and VoiceXML?

[Alex R. <ai...@cs...>]

I agree with Bob's points.

It's indeed quite reasonable to think of VoiceXML as simply an interface 
standard that provides a uniform interface to speech decoding/encoding and 
telephony services. I believe this is the de facto use for it in industry. 
On a more local scale, this is what the students in our Dialog Systems 
Design course (taught by Alan Black and myself) end up doing: apart from 
stuff like the prologue, all vxml pages are generated through cgi scripts, 
where all the real work of running the dialog gets done.

The confusion, unless I missed something important, is that VoiceXML was 
originally presented as a scheme for authoring dialog. You can certainly do 
that but it really doesn't seem to make much sense for anything but the 
most trivial systems. Practitioners have realized this. [But there may be 
someone around here who can speak more authoritatively to the history of 
the idea.]

The state issue thus becomes a bit of a red herring: in reality no one 
really tries to explicitly enumerate all possible states for a system 
(which is in fact what you would have to do if you code directly in vxml); 
they write systems that (hopefully) are capable of generating all necessary 
states. To tie this back to Communicator: most sites, whether explicitly or 
implicitly, tried to develop some "theory" of state generation that would 
do this in a reasonably efficient manner. Notions like "mixed-initiative", 
I think really had to do with the problem of accommodating otherwise 
unanticipatable dialog states.

Alex



At 12:03 PM 2/13/2002 -0500, Bob Carpenter wrote:
>I have three points:  (1) you don't need to use all
>of VoiceXML -- it can be used just as an ASR/TTS engine,
>(2) VoiceXML cleanly separates dialog, ASR and TTS,
>and (3) states + memory = Turing machine, so I'd
>contend that "state-based" systems impose *no* limitations.