Comments to VoiceXML 2.1

Hi !

Some comments to VoiceXML 2.1 Working Draft 23 March 2004 and some more
VoiceXML 2.0. 

As a general comment for <data> elements DOM mapping; I don't see why we
should add more complex programming capabilities into voicexml and once
again make it possible to move the complex application logic into UI side ! 

Chapter 2.  Referencing Grammars Dynamically.

I propose the use of attribute srcexpr in <grammar> element. This will leave
the expr attribute to be used to evaluate the "grammar" content from
javascript content etc. Especially this is handy when data is introduced !

Chapter 3 Referencing Scripts Dynamically'

Once again I propose attribute srcexpr just to make difference between value
for element and 'value that evaluaes to attribute value'..

Chapter 3 Using <data> to Fetch XML Without Requiring a Dialog Transition

Once again I propose attribute srcexpr. Expr attribute could be used as it
is in var. As data is clearly a some kind of extension of <var> element.

Using DOM in <data> is far to complex. I suggest of finding some more
simplified structure for returned data. We could use a simple pattern like..

<data name="temp" src....

and as returned:

<data>

    <property name="a" expr="1">

    <property name="b" expr="-1">

    <property name="c[0]" expr="'temp'">

    <property name="c[1]" expr="'tester'">

</data>

This could then be mapped 

    into javascript 

    temp {

            a = 1;

            b = -1;

            c  = {

                [0] = 'temp'

                [1] = 'tester'

            }

     } 

And so on..  its easy to use it in this way.. Somehow this could be made in
VXML 2.0  with script element too..

Or even use that same mapping we use in SSML to field values

And some more changes that I formerly proposed.. Still waiting for answers
or at least comments..

Dear W3C Committee.. (Probably late fore 2.0 but for 2.1 probably)

Case 1:

I would like to ask you a question about bridge transfer that terminates
with originating caller hang-up. Now the specification states that the event
telephone.disconnect.hangup is thrown when hang-up occurs and field item
does not get filled. As stated in chapter 2.3.7.2.2. 

Record (someone probably thought voicemail in here) is different; It is
stated that the record field item gets filled if something was recorded in
case of hang-up. 

To make it more clear to application developer the <transfer/> should not
differentiate form <record/> it should be filled if transfer took place and
the call was terminated with originating caller hang-up. So the Value of
form item variable should be filled with "caller_hangup" and the appropriate
field items should be filled too. This makes it possible to obtain call
information for logging, billing etc. I think that this is very important
cause platform provider call logs are rarely available to application
provider. So the field gets filled and event "telephone.disconnect.hangup"
is thrown. This makes sense to me..

Case 2:

Somewhat I propose here little different approach for FIA in these special
cases for "collection of event and field information at the same time".
Firstly the FIA could work so the first the appropriate field items get
filled and "just_filled" list is managed as usual. After; this before
evaluating the need of processing any <filled/> elements , the event thrown
gets processed and if it does not cause any transition the appropriate
<filled> elements gets called. I found this very useful and I can give you
some examples if needed.