VoiceXML 2.0: Official Response #2 to Candidate Recommendation Issues

The Voice Browser Working Group (VBWG) is now completing its resolution
of 
issues raised during the review of the Candidate Recommendation version
of VoiceXML 2.0 [1]. Our apologies that it has taken so long to respond.

Following the process described in [2] for advancement to Proposed
Recommendation, this is the VBWG's formal response to the issues you
raised.

Please indicate before 26 November 2003 whether you are satisfied with
the VBWG's resolutions, whether you think there has been a
misunderstanding, or whether you wish to register an objection.

If you do not think you can respond before 26 November, please let me
know. The Director will appreciate a response whether you agree with the
resolutions or not. However, if we do not hear from you at all by 26
November 2003, we will assume that you accept our resolutions.

Below you will find a summary of the VBWG's responses to each of your
issues. Please use the issue identifiers when responding.

Thank you,

Scott McGlashan
Co-chair, Voice Browser Working Group

[1] http://www.w3.org/TR/2003/CR-voicexml20-20030220/ 
[2] http://www.w3.org/2003/06/Process-20030618/ 


-----------------------------------------------
Issues you raised and VBWG responses
-----------------------------------------------

Issues: 
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0003.html
CR1-1

http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0011.html
CR2-1

http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0021.html
CR3-1

http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0045.html
CR4-1


Issue CR1-1

I have a question about where the error.badfetch is thrown and caught
when a called document has non existent root document.

Take the following scenario.

The document 1 makes a transition to document 2 whose root document does
not exist.  document 1 and document 2 have error.badfetch handler at the
document level.  Where is the error supposed to be caught?

I think the question could be the same for the following assertion: If a
document's application attribute refers to a document that also has an
application attribute specified, an error.semantic event is thrown.

As i did not get any anwer to the message, i post my query one more
time. The issue is as follows:

	In a document named doc1.vxml, which is a root document (do not
	specify an application attribute in the vxml tag), we transition
to a
	document doc2.vxml.  doc2.vxml refers to a non existing root
document
	(i.e., application attribute set to doc2-root-unexisting.vxml).

As the spec says (chap 1.5.2), " If a document refers to a non-existent
application root document, an error.badfetch event is thrown ", an
error.badfetch is thrown in this case.

The question: where is the error thrown, or in other way, where do i put
the error.badfetch handler to catch the error?

I see 2 possibilities:
- in doc1.vxml, which means that if a document refers to a non existing
root document, it is a badfecth to try to get this document.
- in doc2.vxml, which means that current document has to be initialized
before getting and initializing the root document.

I think this is the same issue with the following assertion in chapter
1.5.2: "If a document's application attribute refers to a document that
also has an application attribute specified, an error.semantic event is
thrown. "

except that, in this case, the error.semantic could also be catched in
the first root document.


CR1-1 Resolution: rejected

The specification allows the error.badfetch event to be thrown in either
the referring document or the referred document. To guarantee that the
error is caught, catch handlers need to be specified in both documents.
This error handling pattern is illustrated in numerous tests in our
implementation report.  

 --------------------------------------------------------------

Issue CR2-1

I need some clarification on this point:

2.3.7.1 Blind Transfer

With a blind transfer, an attempt is made to connect the original caller
with the callee. Any prompts preceeding the <transfer>, as well as
prompts within the <transfer>, are queued and played before the transfer
attempt begins; bargein properties apply as normal.

As the transfer is modal, a bargein can happen only if we define a
grammar under transfer.  But what is the consequence of matching the
grammar with a recognition result while the prompt are played?  What
will be the value of the transfer item variable?


Analysis: 

[Teemu Tingander]

As you said that transfer is always modal the grammars that are inside
<transfer> element are field item grammars and as such they should
filled the field item specified by name tag. But cause this is a
transfer and the specification says that match in grammar of transfer
should terminate the transfer, my opinnion is that the field should be
filled with 'near_end_diconnect' and put the shadow variables as they
should be
f$.duration=0.0,f$.utterance=<what-was-recognized>,f$.inputmode=inputmod
e..

You have the point in here taht specification really does make
difference with the cases

	The possible outcomes for a bridge transfer before the
connection to the callee is established are: and
	The possible outcomes for a bridge transfer after the connection
to the callee is established are:

And it is not clearly said what should be done if bargein happens. This
case should be defined in the first one of those cases. 

This same issue raises with blind as well as bridgerd transfer, and i
used 'near_end_diconnect' to indicate that the caller has requested to
cancel or disconnect the call. 

And what comes in tagging of those grammars, if someone really finds
some reason for that, could explain it more deeply.

[Ken Rehor]
Your summary is correct. The result should be 'near_end_disconnect' if a
caller cancels a transfer by barging in on a prompt, for both blind and
bridge transfers. This is because prompts are queued and played to
completion before the call transfer begins in either case.

The shadow variables would be filled as you describe.

This will be clarified in a future revision of the specification.

CR2-1 Resolution: accepted 

Following the thread responses by Teema Tingander and Ken Rehor, the
specification will be modified to indicate that the transfer item
variable will have the value 'near_end_disconnect' if a caller cancels a
transfer by barging in on a prompt, for both blind and bridge transfers
and the shadow variables will be filled as described above. 

 --------------------------------------------------------------

Issue CR3-1
chapter 2.4 of the VoiceXML (24 April 2002)

Attributes of filled are:

mode Either all (the default), or any. If any, this action is executed
when
     any of the specified input items is filled by the last user input.
If
     all, this action is executed when all of the mentioned input items
are
     filled, and at least one has been filled by the last user input. A
     <filled> element in an input item cannot specify a mode.

namelist The input items to trigger on. For a <filled> in a form,
namelist
	 defaults to the names (explicit and implicit) of the form's
input
	 items. A <filled> element in an input item cannot specify a
	 namelist; the namelist in this case is the input item name.
Note that
	 control items are not permitted in this list.

As i understand these attributes are not permitted in filled elements
which are child of input item.  But the spec do not say what happens in
this case:
- ignore those attributes?
- throw an error (semantic)?

Furthermore, control items items are not permitted in namelist. I
suppose any other ECMA variable are not permitted neither. But how a
voice browser should handle that case? Ignore the non-input variable
elements or throw an error (semantic)?


CR3-1 Resolution: accepted with modifications 

The specification will be modified so that upon encountering a document
containing a <filled> element specifying either a 'mode' or 'namelist'
attribute as a child of an input item, then an error.badfetch is thrown
by the platform. In addition, the specification will also make clear
that an error.badfetch is thrown when the document contains a <filled>
element with a namelist attribute referencing a control item variable. 


   --------------------------------------------------------------

Issue CR4-1

The bargeintype propery is defined as follows:

"speech: The prompt will be stopped as soon as speech or DTMF input is
detected. The prompt is stopped irrespective of whether or not the input
matches a grammar. "

Would this mean that even if no dtmf grammar is active and the user
enter a dtmf, the prompt should be stopped?


CR4-1 Resolution: accepted with modifications 
Yes. If bargeintype is speech then the prompt will be stopped as soon as
speech or DTMF input is detected regardless of if it is a match or not.
Having dtmf grammars active or not does not effect this. Setting the
inputmodes to voice should prevent the DTMF from barging in on the
prompts (although some platforms may have difficulty separating in-band
DTMF from speech). The specification will be clarified as follows:
addition of the words "and irrespective of which grammars are active."
to the end of the sentence "The prompt is stopped irrespective of
whether or not the input matches a grammar" from table 38.

Received on Wednesday, 19 November 2003 14:33:24 UTC