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

Scott,

Please elaborate your comments:

>... 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). 
>...  
> Please let me know if this reply is unsatisfactory, or you want further
> information.

I feel it is unsatisfactory, and I want further information:

1.  Without DEST, what utility will remain in the RECORD element?

2.  Are there any plans to add a general EVAL to VoiceXML, eliminating 
the need for dichotomies such as DEST/DESTEXPR?

Thank you.

Best wishes,
James

> 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 Saturday, 2 February 2002 20:23:21 UTC