RE: VoiceXML 2.0 comments

thank you for your comments on VoiceXML 2.0. We will discuss your
comments at our face2face meeting in early December and get back to you
with a response.

thanks again,


chairman, Dialog Team, W3C Voice Browser Group 

-----Original Message-----
From: George Clelland []
Sent: Friday, November 23, 2001 18:16
Subject: 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
     transfer would be useful, where the interpretor disconnects from
     telephone call after a successful connection has been established
     the third party. This would be beneficial for call centre
     The text associated with the code example give in section 3.1.5 has
     error. The text states the result will be "AMEX if the caller
     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
     philosphy of voiceXML is to make speech applications easier to
     and minimise the specialist speech knowledge required, elements
     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
     clarifies the operation of interpretors. However, I believe the
     current operation is flawed in that it forces the use of fetchaudio
     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
     current operation, this prompt is not played to the caller until
     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
     as soon as a document is to be fetched and then the fetchaudio if
     specified, this is much more obvious form of operation for
     I would like to propose an additional fetch property (section
     .... fetchaudiorepeatdelay ==> defined as the delay between
     plays of the fetchaudio.

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

Received on Wednesday, 28 November 2001 03:57:47 UTC