RE: More W3C VXML specs feedback

Guillaume,

thank you for more comments on VoiceXML 2.0. As I said previously, we
cannot guarantee that they will be addressed within 2.0 since they were
sent after the Last Call Comment period ended.

thanks again

Scott



-----Original Message-----
From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
Sent: Wednesday, June 26, 2002 18:04
To: Scott McGlashan
Subject: RE: More W3C VXML specs feedback


Scott,

I have some more VXML comments that might be useful and seem to me as
more
problematic. Sorry about not waiting for your answer to my last mail,
but I
won't be reading my mail until next monday, so I thought that in doubt
I'd
send them to you ASAP if they might help.


1) Problem with section "1.5.4 Final Processing"

This section states that "While in the final processing state the
application must remain in the transitioning state and may not enter the
waiting state (as described in Section 4.1.8). Thus for example the
application should not enter <field>, <record>, or <transfer> while in
the
final processing state. The VoiceXML interpreter must exit if the
VoiceXML
application attempts to enter the waiting state while in the final
processing state.
"

While section "4.1.8 Prompt Queueing and Input Collection" states
"Similarly, asynchronously generated events not related directly to
execution of the transition should also be buffered until the waiting
state
(e.g. connection.disconnect.hangup). "
However, since a single event triggers a transition to the
transitionning
state, those two descriptions conflict.
Imagine the following situation in which a remote user sends a bunch of
DTMFs and then hangs up, then since events would be sent in sequence,
and
that input would normally trigger a transition to another field which
then
requests a input collection. As currently described in section "1.5.4
Final
Processing", this would result in the interpreter exiting, without
letting
the application catch the connection.disconnect.hangup event.

Suggested modification to section "1.5.4 Final Processing":

The final processing state is entered when the
connection.disconnect.hangup
event is handed to the application. As described in section "4.1.8
Prompt
Queueing and Input Collection", the remote user may be disconnected and
DTMF
may be provided from a previous buffer before the application receives
the
connection.disconnect.hangup event. During the period of time in which
the
remote user is disconnected and final processing state is not yet
entered,
the application may queued prompts and request input as for normal
processing. The buffered input will be used can compared against
requested
input, only DTMF grammars terminating timeouts would be shortened.

While in the final processing state the application must remain in the
transitioning state and may not enter the waiting state (as described in
Section 4.1.8). Thus for example the application should not enter
<field>,
<record>, or <transfer> while in the final processing state (i.e while
handling the connection.disconnect.hangup event). However, the <submit>
tag
is legal. The VoiceXML interpreter must exit if the VoiceXML application
attempts to enter the waiting state while in the final processing state.



2) Modify section "5.3.11 DISCONNECT"
Section "5.3.11 DISCONNECT" states that "Causes the interpreter context
to
disconnect from the user. As a result, the interpreter context will
throw a
connection.disconnect.hangup event, which may be caught to do cleanup
processing, e.g."

I believe this is not a good thing to throw an event in this case
because a
catch clause would not be able to differentiate between a real user
hang-up
or some logic in the application that requested a disconnection. The
suggested cleanup phase can easily done by the application by throwing a
custom event, and in the catch clause performing necessary clean-up and
then
using the <disconnect> element.

Suggested text modification to section "5.3.11 DISCONNECT":
"As a result, the interpreter context will disconnect the remote user
and
exit the interpreter. Note that applications that would be willing to
perform tasks upon disconnection (such as clean up) may rather throw a
custom event, and in the catch clause perform necessary processing prior
to
invoke the <disconnect> element."

Regards,

Guillaume.

> -----Message d'origine-----
> De : Guillaume Berche [mailto:guillaume.berche@eloquant.com]
> Envoyé : mercredi 26 juin 2002 17:51
> À : Scott McGlashan
> Objet : RE: More W3C VXML specs feedback
>
>
> Scott,
>
> Thanks for your quick response. I hope these comments can be
> useful in making the specs better. Sorry about sending them late,
> but this is as I learn more about the specs that I run into some
> troubles and provide comments on. I may send other feedback as it
> goes if you think this can help (may be for a later version than
2.0?).
>
> Cheers,
>
> Guillaume.
>
> > -----Message d'origine-----
> > De : www-voice-request@w3.org [mailto:www-voice-request@w3.org]De la
> > part de Scott McGlashan
> > Envoyé : mercredi 26 juin 2002 17:19
> > À : Guillaume Berche; www-voice@w3.org
> > Objet : RE: More W3C VXML specs feedback
> >
> >
> >
> > Guillaume,
> >
> > thank you very much for your detailed comments. They are much
> > appreciated by the team.
> >
> > Since these comments arrived after the official comment period I
cannot
> > guarantee that they will be address within the 2.0 timeframe, but we
> > will try our best!
> >
> > thanks again
> >
> > Scott
> > [VoiceXML Dialog team leader]
> >
> > -----Original Message-----
> > From: Guillaume Berche [mailto:guillaume.berche@eloquant.com]
> > Sent: Tuesday, June 25, 2002 16:12
> > To: www-voice@w3.org
> > Subject: More W3C VXML specs feedback
> >
> >
> >
> > Hello,
> >
> > Following are some more comments on the VXML W3C Working Draft from
24
> > April
> > 2002. I understand the time frame for comments ended May 24, 2002
but I
> > though they might still be useful (at least to discuss with
> > practitionners
> > if they are not considered for the 2.0 official release).
> >
> > Concerning event catching algorithm:
> >
> > 1) Precise the execution of catch handlers in section "5.2.2 Catch"
> > Section "5.2.2 Catch" seems to imply that handlers are called
> > synchronously:
> > "If a <catch> element contains a <throw> element with the same
event,
> > then
> > there may be an infinite loop:
> > <catch event="help">
> >    <throw event="help"/>
> > </catch>"
> > Suggested text addition: "The FIA appendix C details the execution
after
> > a
> > catch element is executed (in its definition of the "execute" term)"
> >
> > 2) Precise the definition of "execution" in the FIA appendix C to
> > executables from handlers.
> > Suggested text modification:
> > "execute
> > To execute executable content - either a block, a filled action, or
a
> > set of
> > filled actions. If an event is thrown during execution, the
execution of
> > the
> > executable content is aborted. The appropriate event handler is then
> > executed, and this may cause control to resume in a form item, in
the
> > next
> > iteration of the form's main loop, or outside of the form. If a
> > computed-directed transition element(such as <goto>, <link>,
<return> or
> > <submit>) is executed, the transition takes place immediately, and
the
> > remaining executable content is not executed. During the execution
of
> > the
> > event handler, the same rule applies as for the execution of
executable
> > content described above (with respect to execution abortion and
> > transition)."
> >
> > 3) Precise error handling during document initialization (e.g. in
> > document-level <script> and <var> elements)
> > Suggested modification:
> > Move the modified following text from section "5.2.6 Event Types" to
> > section
> > "5.2.2 Catch" (or to a new section, as suggested in comment #4)
> > "Errors encountered during document loading, including transport
errors
> > (no
> > document found, HTTP status code 404, and so on) and syntactic
errors
> > (no
> > <vxml> element, etc) result in a badfetch error event raised in the
> > calling
> > document, while errors after loading (including document
initialization)
> > (such as semantic errors during <script> and <var> initialization),
are
> > raised and handled in the document itself."
> >
> > I could not understand the rationale behind the following statement
in
> > section "5.2.6 Event Types", near to error.badfetch.
> > "Whether or not variable initialization is considered part of
executing
> > the
> > new document is platform-dependent." Can please someone explain why
this
> > behavior would be platform dependent?
> >
> >
> > 4) Precise document initialization
> > As described above in comment #3, some events are handled at
document
> > initialization. However, since elements are initialized in document
> > order,
> > events handlers may not yet be active at the time an event is
thrown.
> > Take
> > for instance the usual case of a vxml document starting with a
script
> > element: no document handlers are yet initialized, and an error in
the
> > <script> element would not be handled by defined event handlers.
> >
> > Suggested modification: add a specific section concerning document
> > initialization similar to the FIA which precise the order of element
> > initializations
> >
> > "1.5.0 Document initialization
> >
> > Document initialization starts once the transport and XML schema
> > validation
> > has been performed.
> >
> > As described in section "5.2.2 Catch", errors occuring during this
phase
> > are
> > raised and handled in the document itself. During handling of
events,
> > the
> > variable scope chain may not be complete (there might be no chained
> > dialog
> > scope yet), but the _event shadown variable is still defined in an
> > anonymous
> > variable scope"
> >
> > Each element is initialized in document order including event
handlers.
> > Consequently, it is advised to define document-level handlers first
in
> > the
> > document.
> > ...
> >
> > Once all elements are initialized, the document execution begins. As
> > described in section "1.5.1 Execution within One Document", document
> > execution begins at the first dialog by default.
> > "
> >
> >
> > 5) Refine anonymous variable scope during event handling
> > Section "5.2.2 Catch" states that "The catch element's anonymous
> > variable
> > scope includes the special variable _event which contains the name
of
> > the
> > event that was thrown."
> > To me, this implies that the handler is invoked when the FIA is
> > currently
> > running (that is a form and a form item are active). However, this
might
> > not
> > be the case for events handled during document initialization.
> > Consequently,
> > the variable scope chain as described in section "5.1.2 Variable
Scopes"
> > would not work, in particular there would no chained dialog scope.
> > Suggested modification is included in comment #4
> >
> >
> > Other feedback
> >
> > 6) Precise that a <field> item without implicit nor explicit grammar
> > should
> > throw an error.semantic event.
> > See if it is possible to refine the schema to enforce this.
> > Alternative suggested text modification to the end of section "2.3.1
> > FIELD"
> > "[...] The use of <option> does not preclude the simultaneous use of
> > <grammar>. The result would be the match from either 'grammar', not
> > unlike
> > the occurence of two <grammar> elements in the same <field>
representing
> > a
> > disjunction of choices. However, a field item without implicit nor
> > explicit
> > grammar would result in an error.semantic event to be thrown at
document
> > initialization time".
> >
> >
> >
> >
> > I hope this can help. Any comment on this is welcome.
> >
> > Best regards,
> >
> > ------------------------------------------
> > Guillaume Berche
> > Eloquant, ZA Le malvaisin
> > 38240 Le Versoud, France
> > guillaume.berche@eloquant.com
> > +33 04 76 77 46 92
> > ------------------------------------------
> >
> >

Received on Friday, 28 June 2002 06:26:19 UTC