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 Tuesday, 3 September 2002 10:04:18 UTC