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,

Scott

chairman, Dialog Team, W3C Voice Browser Group 

-----Original Message-----
From: George Clelland [mailto:george_clelland@uk.ibm.com]
Sent: Friday, November 23, 2001 18:16
To: www-voice@w3.org
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
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 Wednesday, 28 November 2001 03:57:47 UTC