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

Guillaume,

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.

Scott

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
Prompting"



Hello,

This comment relates to the issue in section "4.1.3 Audio Prompting" of
the
VXML W3C Working Draft 24 April 2002: "if events can be thrown as the
result
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
"use-cases":
a - an existing application is executed onto a new interpreter which has
different capabilities (such as different supported audio format,
different
supported language). The developer is trying to program its application
to
programmatically recover from such condition by using different
format/language.
b- in an application composed of multiple documents developped
independently
(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
currently
defined do not provide sufficient information to let an application
programmatically recover from the reported error condition. I believe it
is
not desirable to try to support VXML applications that can dynamically
recover from missing capabilities of their host interpreters and adapt
from
them using client-side logic. This would be too complex and probably
cause
performance problems anyway.

In my opinion, two approaches can be followed to account for the
different
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
the
interpreter. This is self-degradation which is different from
programmatic
recovery of failed prompt.
2- Server-side approach: follow the HTML model in which the client-side
(the
VXML browser) provides information about its capabilities, and the
server-side dynamically adapts content to the "rendering" capabilities
of
the client. Therefore, a later version of the VXML specifications may
precise semantics of standard HTTP headers (such as "Accept" which
specifies
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
for
application developers to enter a mode in which failed prompts are
silently
ignored. This could be achieved through an additional property (such as
"ignorebadprompts"). This property would be resolved in the property
scope
of the form item which triggers entering of the waiting phase. Therefore
case a) would simply be handled by defining the "ignorebadprompts" in
the
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
can
trigger a submit element targetting a page sending an email report for
instance).


For the VXML specification 2.0, I would suggest to clarify the intent of
the
events thrown by the interpreter to precise they support application
development and tuning, but the specs do not expect applications to
recover
from such conditions. Possibly document the future intent of client-side
and
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
that
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
the
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
page
to the end-user). A possible extension of VXML in a future version would
be
to support client-side and and server-side browser capabilities
discovery
which lets both the VXML application (or application server generating
VXML
content) to dynamically degrade/adapt the application to the
capabilities of
the host interpreter. Note that the support for programmatic error
recovery
from failed prompts will probably not be enhanced in future versions."

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

Any comment on this is welcome.

Guillaume.

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