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

It seems to me that using record without dest, implies that one should
submit values to a web server, if you need to do any permanent storage of
that recording. (You could also probably do some tricky stuff in script, if
the VXML platform sufficiently exposes access to the recorded value)

This is fine, if you are trying to write voice portal style applications, or
any application that is merely trying to provide a voice interface to legacy
web data/processes.  And this is fine, if you like using the http/submit
model for implementing the final storage of data that is interactively
collected from the user.

However, if you are trying to code a traditional IVR, or even voicemail
application, it is clumsy and can be inefficient to make a round trip to the
server, when you could instead, store the files locally on the machine
(without a web server)  where the VXML interpreter resides.

In fact, there are many applications that can be coded in VXML today, that
never do any submits.

As for en eval() feature:  instead of adding something like that,  you could
allow expressions only (where expressions are needed), and not have two
versions of every attribute that may need a literal value or expression.
This would just mean quoting literal values, rather then choosing the
literal attribute version, when an expression is not needed.  I think this
is less confusing than trying to figure out which version of an attribute
you need to use.

Just my two cents.

-- Randy

----- Original Message -----
From: "Scott McGlashan" <scott.mcglashan@pipebeach.com>
To: "James Salsman" <j.salsman@bovik.org>
Cc: <www-voice@w3.org>
Sent: Monday, February 04, 2002 7:26 AM
Subject: RE: VoiceXML2.0: Missing "destexpr" attribute in specification of
<record> element


> James,
>
> thank you for your public response to VoiceXML.
>
> To address your specific points:
>
> 1. <record> has considerable value without 'dest' --- see numerous
> publications (e.g. VoiceXML Review
> http://www.voicexml.org/Review/index.html), conference presentations and
> even the specification itself for such uses of <record>. For example, a
> basic voice mail record and playback service can be built.
>
> 2. There are no public plans to add a general EVAL feature to VoiceXML
> 2.0.
>
> Due to W3C member confidentially, I cannot go into the details of
> specific technical decisions or even specific features which are being
> considered for future versions (until that information is made public by
> the group). If you are seriously interested in that level of technical
> discussion I would encourage you to join the Voice Browser Group --- see
> http://www.w3.org for membership details. This will give you access to
> our internal discussions and decision-making process.
>
> Please let me know if this reply is unsatisfactory, or you want further
> information.
>
> thanks
>
> Scott
>
> (Chairman, W3C VB VoiceXML Committee).
>
>
>
> -----Original Message-----
> From: James Salsman [mailto:j.salsman@bovik.org]
> Sent: 03 February 2002 02:23
> To: Scott McGlashan
> Cc: www-voice@w3.org
> Subject: 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 Thursday, 7 February 2002 18:38:21 UTC