W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2002

RE: VoiceXML2.0: Missing "destexpr" attribute in specification of <record> element

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Tue, 29 Jan 2002 15:23:15 +0100
Message-ID: <2764A29BE430E64A92EB56561587D2E70633C4@se01ms02.i.pipebeach.com>
To: "Wyss, Felix" <FelixW@inin.com>, <www-voice@w3.org>
thank you for your public comment on VoiceXML. 
 
The issue you described has already been discussed within the W3C
VoiceXML team. Due to a number of unresolved technical issues around the
"dest" attribute, it is expected that the next Working Draft of the
VoiceXML 2.0 specification will remove the "dest" attribute from
<record> (hence, 'destexpr' is no longer relevant). 
 
An internal version of the draft is available to Voice Browser Working
Group members at
http://www.w3.org/Voice/Group/2002/voicexml20/WD-voicexml20-20020119.htm
. The public version is expected in March 2002. 
 
Please let me know if this reply is unsatisfactory, or you want further
information.
 
thanks
 
Scott
 
(Chairman, W3C VB VoiceXML Committee).

_______________

Scott McGlashan
CTO
PIPEBEACH
Box 24035/Karlav. 108
SE-104 50 Stockholm, Sweden
fax:       +46 8 54590993
office:    +46 8 54590990
mobile:    +46 708 462432


www.pipebeach.com

-----Original Message-----
From: Wyss, Felix [mailto:FelixW@inin.com]
Sent: 26 January 2002 22:14
To: www-voice@w3.org
Subject: RE: VoiceXML2.0: Missing "destexpr" attribute in specification
of <record> element


If I understand it correctly, the "dest" attribute of <record> allows to
explicitly specify the destination of the recording for platforms that
support it.  For example, a platform that can directly record into WAV
files could allow the "dest" attribute to specify the path to the
recording (e.g. dest="file://c:\recordings\greeting_johndoe.wav").  
That is obviously different than recording into memory and then
submitting it to the document server using <submit> as you suggest.  

The "destexpr" attribute would allow synthesizing the filename at
runtime based on an ECMAScript expression, which can be very useful.  In
the above example, the userid could be appended at runtime, thus
allowing reuse of the same VoiceXML document for different sessions
instead of forcing the document server to assemble a new VoiceXML
document for each userid.  I therefore think the standard should allow
for a "destexpr" attribute in the <record> element.  

Felix

-----Original Message-----
From: James Salsman [mailto:j.salsman@bovik.org]
Sent: Saturday, January 26, 2002 13:14
To: Wyss, Felix
Cc: www-voice@w3.org
Subject: Re: VoiceXML2.0: Missing "destexpr" attribute in specification
of <record> element


> The VoiceXML 2.0 specification introduces a "dest" attribute for the 
> <record> element.  However, there is no "destexpr" attribute (similar 
> to <transfer>).  I presume this is an omission in the working draft.

Perhaps you can use RECORD's NAME attribute in conjunction with the 
SUBMIT element's NAMELIST, METHOD=POST, and
ENCTYPE="multipart/form-data"?

Speaking of omissions in VoiceXML drafts, I notice that Lernout & 
Hauspie left endpointing (also called segmentation and alignment) 
out of the so-called semantic interpretation working draft:

  http://www.w3.org/TR/2001/WD-semantic-interpretation-20011116/

even though they produce a product to accomplish the required task.

Anyway, with the large number of low-cost and no-cost recognition 
systems presently available, a handful of which have endpointing 
features built-in, this sorry state of affars is surmountable.  
However, VoiceXML is presently incapable of the task.

Endpointing is essential to perform the operations described on:

  http://llt.msu.edu/vol2num2/article3/#Figure3

Best wishes,
James
Received on Tuesday, 29 January 2002 09:21:04 GMT

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