VoiceXML 2.0 comments

I have some personal comments on the VoiceXML 2.0 Working Draft.

     An additional form of transfer would be useful. A standard supervised
     transfer would be useful, where the interpretor disconnects from the
     telephone call after a successful connection has been established with
     the third party. This would be beneficial for call centre
     applications.
     The text associated with the code example give in section 3.1.5 has an
     error. The text states the result will be "AMEX if the caller enters
     DTMF 1; the text should say DTMF 3.
     Many of speech markup elements are too complex for application
     programmers, and should only be used by specialists.  Given that the
     philosphy of voiceXML is to make speech applications easier to develop
     and minimise the specialist speech knowledge required, elements such
     as <prosody> and <phoneme> seem to contradict this goal.
     The first code example in section 4.1.3  has an error. The <say-as>
     element has an old parameter, namely class rather than type.
     The discussion on prompt queuing and input collection in section 4.1.8
     clarifies the operation of interpretors. However, I believe the
     current operation is flawed in that it forces the use of fetchaudio in
     order to have a prompt at the end of one document played before the
     next document is fetched.  A typical call flow will have a prompt
     telling the caller to wait while some data is retrieved, but with the
     current operation, this prompt is not played to the caller until after
     the second document is fetched, unless fetechaudio is used. This is
     not an  intuitive operation, as the addition of the optional
     fetchaudio changes the way the application works and leads to
     unexpected results. I would propose that all queued prompts are played
     as soon as a document is to be fetched and then the fetchaudio if
     specified, this is much more obvious form of operation for application
     developers.
     I would like to propose an additional fetch property (section 6.3.5)
     .... fetchaudiorepeatdelay ==> defined as the delay between successive
     plays of the fetchaudio.


George Clelland
EMEA Voice Systems
DirectTalk & Message Center pre-sales Technical Support
IBM UK Laboratories
Hursley Park, Mail Point 104
Winchester
Hants, UK  SO21 2JN
email: george_clelland@uk.ibm.com      Tel: +44 (0)1962 816657    Fax: +44
(0)1962 816800

Received on Friday, 23 November 2001 12:16:47 UTC