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

Randy,

thank you for your input on VoiceXML. We will take into consideration
your thoughts on eval for future versions.

Scott

(Chairman, W3C VB VoiceXML Committee)




-----Original Message-----
From: randy [mailto:rsolton@zygot.com]
Sent: 07 February 2002 20:52
To: Scott McGlashan; James Salsman
Cc: www-voice@w3.org
Subject: 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 Friday, 8 February 2002 07:54:13 UTC