Comments on the First Working Draft of VoiceXML 2.1

I'm a little behind on my reading, but I figure for a working draft comments
are still useful.

1)	In Section 2, I agree with the comments on this list that "srcexpr"
is a better attribute name, both for consistency and in case someday it is
desired to use an expression to be the content of the element rather than
the source. I would not advlocate adding the "expr" attribute in addition as
I'd rather see a cleaner way of handling dynamic grammars than using script
to put the entire grammar into a variable.  How about allowing <value> in an
inline XML grammar (although I realize this is more of an SRGS problem at
that point or at least there would be an interaction)?
2)	In section 3, I do not see the value of this construct.  The example
shows it being used to pass a parameter to the script being included, but
since the script functions by definition accept parameters, why pass in a
parameter to load different scripts? In general this smacks of
self-modifying code a little bit.  If you are going to call functions in a
script file, the function definitions should be included statically. Maybe
another example could convince me. The best example I can come up with would
be a set of language specific includes, but I think that can be handled
better in other ways as well.
3)	I agree with comments that the data element seems to encourage
designing far too much of an application as client-side script instead of
using an n-tier model.  I would prefer it not be added. At a minimum it
should be optional as it should not be encouraged as an appropriate design
pattern.
4)	If the data element is needed, I think the VBWG should avoid
defining its own data access protocol like this.  The current design
encourages too much interdependency between the VoiceXML document and the
XML service.  Defining a new protocol like this opens up lots of work to be
done in the areas of versioning, security, etc.  I recommend replacing it
with a mechanism to call SOAP web service (if it is left in at all) with
clearly specified parameters and return values.
5)	The access control on the data element does not seem to be very
secure.  It seems to assume the browser is a trusted entity (since the
credentials are fetched along with any sensitive data, the browser already
has  the sensitive data).  I suppose it is trying to protect against
malicious VoiceXML in a hosted environment, but that is only one deployment
option for a VoiceXML browser. I think any security needs to be removed from
the XML and moved into lower levels of the protocol.  Perhaps supplying
credentials for a web server level validation is enough.
6)	Section 9 - "consultation" implies that a dialog occurs on the
second call leg.  If we want to allow that feature, I would also add a
<connect> tag to complete the transfer.  I think "monitored" or
"monitoredblind" might describe it better. An alternative would be to drop
this proposal and instead add an "answermode" attribute with values
"immediate", "startvoice", "endvoice" etc.  There are a lot of variations on
single-line transfers and deciding when a call is complete. Far-end answer
is not well defined in general, depending on the protocol - our platform
currently offer these choices as configuration parameters but sometimes it
is necessary to  set on a call by call basis (e.g. an international number
might behave differently).
7)	Could add more event values for completion: "SIT" (special
information tone), "answeringmachine", etc. Are these implicitly allowed as
platform specific return values or does it need to be explicit?

Hope these make some sense and are useful,
Ken
________________________________________________
Ken Waln
Chief Technology Officer
Edify Corporation
kenw@edify.com
(408)982-2050
www.edify.com
or call our automated attendant at 800-713-3439 (71Edify) and ask for Ken
Waln or Ken Waln Cell Phone

-----Original Message-----
From: Max Froumentin [mailto:mf@w3.org]
Sent: Tuesday, March 23, 2004 8:47 AM
To: www-voice@w3.org
Subject: First Working Draft of VoiceXML 2.1 published


The W3C Voice Browser Working Group is glad to announce the publication
of the first Working Draft of VoiceXML 2.1.

Abstract: VoiceXML 2.1 specifies a set of features commonly
implemented by Voice Extensible Markup Language platforms. This
specification is designed to be fully backwards-compatible with
VoiceXML 2.0.

The document is at http://www.w3.org/TR/2004/WD-voicexml21-20040323/

Please send comments to this mailing list.

Max Froumentin 
for the Voice Browser WG

Received on Wednesday, 2 June 2004 20:20:24 UTC