W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2004

RE: Comments on VoiceXML 2.1 draft specification

From: MattO <matto@tellme.com>
Date: Tue, 20 Apr 2004 13:14:18 -0700
To: "'Robert Keiller'" <robert.keiller@voxsurf.com>
Cc: <www-voice@w3.org>
Message-ID: <003501c42714$0fa22410$8b9d9dd1@sea.tellme.com>

Hi, Robert.

Thanks for your comments on VoiceXML 2.1. The Voice Browser Working Group
will discuss your comments and get back to you with a response.

Matt

VoiceXML 2.1 Editor, W3C Voice Browser Group

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf
Of Robert Keiller
Sent: Monday, April 19, 2004 10:02 AM
To: www-voice@w3.org
Subject: Comments on VoiceXML 2.1 draft specification

Firstly I would like to say that these small changes address some very
useful additions to VoiceXML.

I am slightly disappointed that the support for <mark> does not go further
and support client side audio control. application.lastresult$.marktime will
support very simple audio control by sending the marktime as a url parameter
in an audio request and having the application server apply offsets to the
original audio file. However, there are two important cases where this will
not work:
- TTS prompts
- where several audio files have been queued together  (putting a mark on
every prompt in the queue and
  restarting the prompt queue from the last mark would be very awkward
solution) I believe that several voice browsers already support greater
functionality via non-standard extensions and it seems a pity that these
could not be standardised in VoiceXML 2.1.

I also think Teemu Tingander raises a good question about the naming of the
expr attributes for <script> and <grammar>. (Logically the expr attributes
on <audio>, <next> and <submit> should also be srcexpr. <subdialog> already
uses srcexpr, but expr in this case is an asignment 
of the subdialog variable, not a definition of the subdialog fetch.) Even if
there is no immediate intention to support dynamic grammars via <grammar
expr="..."/> where expr evaluates to an actual grammar, it seems a mistake
to close off that possibility in future.

Robert
Received on Tuesday, 20 April 2004 16:16:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:59 GMT