W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2002

RE: Comment on alternate prompt issue from section "4.1.3 Audio Prompting"

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Thu, 5 Sep 2002 14:00:02 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107F33@se01ms02.i.pipebeach.com>
To: "Guillaume Berche" <guillaume.berche@eloquant.com>, <www-voice@w3.org>


thank you for your input. Unfortunately, input on this issue was
required within the official comment period which ended on the 24th May
2002 as is clearly stated in the specification. The group has already
discussed this issue and it is too late to take your input into account.
You, of course, will another opportunity to comment on the specification
when the next version is published.


VoiceXML dialog team leader, VBWG

-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Tuesday, September 03, 2002 16:04
To: www-voice@w3.org
Subject: Comment on alternate prompt issue from section "4.1.3 Audio


This comment relates to the issue in section "4.1.3 Audio Prompting" of
VXML W3C Working Draft 24 April 2002: "if events can be thrown as the
of the prompt playing possibly unrelated to the input collection, this
forces VXML authors to defensively code against possible audio failures
unrelated to their content. [...]"

I tried to clarify the need for such defensive code by listing such
a - an existing application is executed onto a new interpreter which has
different capabilities (such as different supported audio format,
supported language). The developer is trying to program its application
programmatically recover from such condition by using different
b- in an application composed of multiple documents developped
(such as a voice portal), a caller document has queued prompts which
fail to
be played while the called document is running.

I believe that the VXML language should not try to support recovery of
conditions such as case a), rather events should be used to help authors
diagnose errors; the application itself should not try to recover
programmatically from it. This is because VXML events as they are
defined do not provide sufficient information to let an application
programmatically recover from the reported error condition. I believe it
not desirable to try to support VXML applications that can dynamically
recover from missing capabilities of their host interpreters and adapt
them using client-side logic. This would be too complex and probably
performance problems anyway.

In my opinion, two approaches can be followed to account for the
capabilities of the host interpreter:
1- Client-side approach: expose to the VXML document standard session
variables that describe the capabilities of the platform. This way the
application may degrade itself smoothly to the available capability of
interpreter. This is self-degradation which is different from
recovery of failed prompt.
2- Server-side approach: follow the HTML model in which the client-side
VXML browser) provides information about its capabilities, and the
server-side dynamically adapts content to the "rendering" capabilities
the client. Therefore, a later version of the VXML specifications may
precise semantics of standard HTTP headers (such as "Accept" which
the supported media formats or  "Accept_Language") that specify the
capabilities of the VXML host platform (such as supported language,
supported audio formats...)

Concerning the case b) described above, I believe there should be a way
application developers to enter a mode in which failed prompts are
ignored. This could be achieved through an additional property (such as
"ignorebadprompts"). This property would be resolved in the property
of the form item which triggers entering of the waiting phase. Therefore
case a) would simply be handled by defining the "ignorebadprompts" in
usual entry point of the document. It would be usually the case that the
rest of the application does not define this property to preserve the
automated detection of failed prompts from the application itself (which
trigger a submit element targetting a page sending an email report for

For the VXML specification 2.0, I would suggest to clarify the intent of
events thrown by the interpreter to precise they support application
development and tuning, but the specs do not expect applications to
from such conditions. Possibly document the future intent of client-side
server-side capabilities discovery as described above.

Suggested text addition to section "4.1.3 Audio Prompting":
"When a prompt fails to be played (for various reasons such as an
unsupported language, or an audio prompt which can not be fetched and
without alternative prompt), then the appropriate event is thrown. Note
the VXML language is not designed to support automatic recovery from the
failed prompt. Rather, thrown event is designed to allow VXML authors to
automate detection of errors and possibly their reporting (by catching
error and transitionning to a submit form item connected to a page which
triggers an email notification on the server-side and returns an error
to the end-user). A possible extension of VXML in a future version would
to support client-side and and server-side browser capabilities
which lets both the VXML application (or application server generating
content) to dynamically degrade/adapt the application to the
capabilities of
the host interpreter. Note that the support for programmatic error
from failed prompts will probably not be enhanced in future versions."

Please let me know if wording suggestion concerning the
property would be useful.

Any comment on this is welcome.

Received on Thursday, 5 September 2002 08:01:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:36 UTC