Comments on VoiceXML 2.1 CR

Hi,

After reading the CR, I have the following comments on 2.1. (as both a
VoiceXML developer, hoster and browser developer...)

1/ <data> : I find this to be a fustrating construct - not IMHO powerful
enough to deal with most real world cases, but nontheless an encouragement
to the development of more application logic in ecmascript.
[NOT IMHO a good thing, as it is a) hard to maintain/debug b) hard to
dimension capacity on the browser server side and c) makes visual basic look
efficient.....]

The requirement to support a read-only DOM environment seems to be to
another "heavy" addition to the browser ECMAScript requirements.....

In practise, I find that either
	- the back end application server returns data that is not a nice XML
format, so requires a real intermediary component,
	- or (better) the server be modified to return directly a vxml subdialog
response form - directly parsable by the brower, can set variables exactly
as required etc.

In my opinion, this construct does not cover many useful cases, and confuses
even more the use of VoiceXML - is it a programming language? an api? a
dialog definition?

I think a standard definition of a mapping from a subdialog call to a
WebService call might have been interesting....

2/ foreach : I agree with the remark made by another poster : this can help
with certain specific prompt building cases, but again encourages the
developer to try to put too much code into the vxml form, and does not cover
all the useful cases. Equally I agree the text needs clarification as to
exactly when it can be used, and what can be included as its children to
avoid convoluted and non-deterministic behaviour.

3/ srcexpr attribute for grammar : this is stated as being evaluated at each
activation of the grammar. IMHO, this can easily lead to delays for grammar
activation, as the browser can do no pre-fetch or caching of the grammar,
and so all processing will be done at the activation time! Some applications
(not neccessarily well written, but real apps) tend to generate a lot of
little grammars to be fetched from the app server - if these are to be
fetched at the input time then performance and scalability would seem to me
to be hard.

If the expression was evaluated only when the grammar is initially fetched
(when it comes into context) then most of the benefit of the expr can be
obtained without the performance problems?

4/ srcexpr attribute for script : this is stated as being re-evaluated each
time the script "needs to be executed". Does this mean when the script tag
is processed (entry into its context), or each time a function declared in
the script is to be executed? The former seems reasonable, the 2nd very
hard.....

5/ addition of namelist for disconnect : I don't understand the point of
this - control is not explicitly returned to the interpreter context by a
disconnect execution, only by an exit. Why is it a problem for an
application to use disconnect to hangup the caller, and use an explicit exit
to return control at some later point, with the existing exit namelist
attribute?

6/ type attribute for transfer to add "consulation" type : why not simply
redefine the blind transfer to function in this way? To 'enhance' transfer
with extra call control features seems kind of pointless - if greater call
control is required then use CCXML.... I have seem other "minor" extensions
to transfer to allow enhanced call control (eg to play a message to the
destination before the bridge, be able to set outbound signalling parameters
etc); I'm not sure this particular enhancement has any greater merit that
justifies its inclusion....

In summary, although I agree a couple of the 2.1 additions are useful (in
particular srcexpr for grammar/script), I think that 2.1 in general does not
add significant value, will lead to a certain amount of doubt and
incompatibility in the application developer world, and therefore slow down
adoption and deployment of VXML 2.0. I would rather see standardisation work
in the areas of higher level application definition languages (as being
undertaken by the VoiceXML Forum tools group) to enable better
development/debug tools to increase the mass of vxml applications out there
and in use.

Anyway, thats my 2c (euro of course) worth.....

Brian

[ Brian Wyld : Eloquant SA    ]
[ Directeur technique         ]
[ brian.wyld at eloquant.com  ]
[ tel: +33 476 77 69 54       ]
[ mob: +33 609 62 10 87       ]
[ fax: +33 476 77 40 65       ]

Received on Friday, 24 June 2005 12:03:53 UTC