[dialog] Tingander #2 - VBWG official response to VoiceXML 2.0 Last Call Review Issues

The Voice Browser Working Group (VBWG) has almost
finished resolving the issues raised during the last call
review of the 24 April 2002 VoiceXML 2.0 [1]. Our apologies that 
it has taken so long to respond.

Although your comments were outside the official comment
period, this is the VBWG's formal response to the issues you raised,
which have been logged in the Working Group's issues list [4].
The VBWG's resolutions have been incorporated into the 18 October
2002 draft of the VoiceXML 2.0 [5]. 

Please indicate before 5th November 2002 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 5th November, please let me
know. The Director will appreciate a response whether you agree
with the resolutions or not.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's responses to each of your issues.

Thank you,

Scott
Co-Chair, VBWG

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 5.2.3 [2] of the 19th July 2001 Process Document, in
order for the VoiceXML 2.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:

  "In the context of this document, a Working Group has formally
  addressed an issue when the Chair can show (archived) evidence
  of having sent a response to the party who raised the
  issue. This response should include the Working Group's
  resolution and should ask the party who raised the issue to
  reply with an indication of whether the resolution reverses the
  initial objection."

If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.

If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. 

[1] http://www.w3.org/TR/2002/WD-voicexml20-20020424/
[2] http://www.w3.org/Consortium/Process-20010719/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010719/groups.html#WGVotes
[4] http://www.w3.org/Voice/Group/2002/voiceXML-change-requests.htm
(members only)
[5] http://www.w3.org/Voice/Group/2002/WD-voicexml20-20021018.htm
(members only)
(http://www.w3.org/Voice/Group/2002/WD-voicexml20-20021018.zip) (members
only)

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
In http://lists.w3.org/Archives/Public/www-voice/2001OctDec/0044.html
and 
http://lists.w3.org/Archives/Public/www-voice/2002JanMar/0062.html you
raised 
the following issues which were registered as dialog change requests
R419 and R426. 
Our response is given inline after each issue.


[1] While reading spec 2.0 I found following "problem". 
	--> Taken form W3C VoiceXML 2.0 draft
	in chapter 4.1.6
	"Each form item and each menu has an internal prompt counter
that is
reset to one each time the form or menu is entered. Whenever the system
uses
a prompt, its associated prompt counter is incremented. This is the
mechanism supporting tapered prompts."
So the question is : 
Are prompt counts maintained for <form/> and <menu/> elements only or
are
they maintainded for each <*form item*> - specified in chapter 2.1.2  ?
 If we are working like in events; Counters are reseted when entering
<form/> or <menu/>  and we have individual counter for each <*form
item*> ,
but initial uses <form/>s counters. This is right? 
So does this mean that when  <goto item="this" /> occurs in field "that"
while field "this" has prompt counter 3 the prompt that has count 3 is
selected. So entering <field name="this">..</field> does not reset
counter.
So returning to  <*form item*> that has prompted something before
maintains
<*form item*>s prompt count and allows us to do "tapared prompting",
yeah ? 

VBWG Response: Accepted.

In Section 5.2.2 of the lastest version [5], we have clarified in the
description of "count" attribute of <catch> when counters are reset: 

"The occurrence of the event (default is 1). The count allows you to
handle different occurrences of the same event differently. 
Each <form>, <menu>, and form item maintains a counter for each event
that occurs while it is being visited. Item-level event counters are
used for events thrown while visiting individual form items and while
executing <filled> elements contained within those items. Form-level and
menu-level counters are used for events thrown during dialog
initialization and while executing form-level <filled> elements. 

Form-level and menu-level event counters are reset each time the <menu>
or <form> is re-entered. Form-level and menu-level event counters are
not reset by the <clear> element. 

Item-level event counters are reset each time the <form> containing the
item is re-entered. Item-level event counters are also reset when the
item is reset with the <clear> element. An item's event counters are not
reset when the item is re-entered without leaving the <form>. 

Counters are incremented against the full event name and every prefix
matching event name; for example, occurrence of the event "event.foo.1"
increments the counters  for "event.foo.1" plus "event.foo" and "event".



[2] EVENT HANDLING:

As Jean-Michel Reghem [reghem@babeltech.com] in his mail about events
already pointed out there seems to be some unanswered questions in event
handling in field elements. 

We seem to have 2 different kind of field elements from the event
handling
point of view  This makes it difficult to application developer to
always
know where FIA´s going. Solutions for these problems may be easily
solved in
FIA, but I hope that this is not the path that we want to follow.
<object>
is out from this discussion cause it already is quite difficult for
application developer.

In field elements  <field> <initial> event thrown in collect phase (
like
event "nomatch" ) prevents field to be filled unless otherwise assigned
in
catch handler and by doing this  prevent <filled> execution. This makes
sense to me. 
	
How ever handling events in <subdialog> this is not clear. The VXML 2.0
Draft specifications section 5.3.10 it is mentioned that ; 
	"In returning from a subdialog, an event can be thrown at the
invocation point, or data is returned as an ECMAScript object" 
and also after example : 
	"The subdialog event handler for <nomatch/> is triggered on the
third failure to match; when triggered, it returns from the subdialog,
and
includes the nomatch event to be thrown in the context of the calling
dialog. In this case, the calling dialog will execute its <nomatch/>
handler, rather than the <filled/> element, where the resulting action
is to
execute a <goto/> element. Under normal conditions, the <filled> element
of
the subdialog is executed after a recognized social security number is
obtained, and then this value is returned to the calling dialog, and is
accessible as result.ssn"
It would clarify the thing quite if that example wouldn't have that
<goto/>
element. because it anyways causes FIA to exit. So should the field
remain
unfilled and visited again, like in <field>. I think that is should. BUT
then we go to VoiceXML.orgs conformance examples and the first subdialog
example. In my opinion it should end into endless loop. This would make
sense in <field> like event handling. This needs to be clarified in
specification. In the case of event; if field is not needed to be
visited
again <subdialog> elements cond change or <assign> to fill the field ,
like
in <field>, could be used.

The case with <record> element is almost the same as in <subdialog> but
even
more complicated . Lets start form FIA side of the view; As the
specification says FIA only has 2 states : Processing input and document
and
Collecting user input ( Events OR Utterances )  The combining first and
second example of <record/>:
<?xml version="1.0"?>
<vxml version="2.0">
   <form>
     <record  name="greeting" beep="true" maxtime="10s"
finalsilence="4000ms" dtmfterm="true" type="audio/wav">
	.. no change here ..
     </record>

     <field name="confirm" type="boolean">
	.. no channge here ..
     </field>
     <catch name="telephone.disconnect.hangup">
	<if cond="greeting">
	           <submit next="save_greeting.pl" method="post"
namelist="greeting"/>
	</if>
     </catch>
   </form>
</vxml>

This comes much about the underlying system but I think that if there
was
something recorded on underlying layer ( in here we have to think
silence
detection etc. systems ) and then hang-up ,  the collection phase in
field
"greeting" should return the Utterance then on the collection phase for
confirm the <event> telephone.hangup will be connected form underlying
system and normal catch handling will take place.  This is the case if
collection phase produces only  Events OR Utterances not BOTH. If I
havent
already brought it up I think that field gets filled only if event is
not
thrown in collection phase. < form> level <catch> will handle this quite
neatly 

The field elment <transfer> is like <field> to me. Should it be ( so in
case
of blind transfer )  the event is handled and field is not filled.
Hopefully that <catch> does the <exit/> or similiar. Is this the case
with
<disconnect>;  in specification for <blind> transfer  " The interpreter
disconnects from the session and continues execution (if anything
remains to
execute) but cannot regain control of the call. The caller and callee
remain
connected in a conversation "

This is all about event handling .. There were few clarifications about
event counting issues that I pointer in my earlier mails.


VBWG Response: Rejected.

We are unclear exactly what this issue is about since it spans a number
of different points. Please re-formulate more clearly.


[3] DOCUMENT TRANSITIONS ..

VXML 2.0 draft introduces more transitions within document, and some of
these are not clearly explained. I would like to have some
clarifications
into specification to make application developers life little easier. 

I hope We all know the scoping of attributes and paramaters. Ill try to
explain the problem.

	We have document 1 which is a Application Doc for doc 2 like on
specs figure 3. 

	In step 1 . Doc is an application root ,  but we dont know this
at
this time .. So should we initialize the variables in doc scope of doc 1
into scope document, Yes. But as said Root document is application by
itself
( in spec Root2Root; "The root context is initialized with the new
application root document, even if the documents are the same or have
the
same application name" ) so should variables ( and parameters ) in scope
application be identical ( application == document ). ok.  lets keep it
this
way. Should there be variables in scope application at all ? 
	In Step 2. The doc scope should be replaced with variables for
leaf
doc 2. Right because this is the "doc" that we are executing .  Yep This
is
easy. 
	In Step 3. Same thing but with variables form doc 3 
	In Step 4. Do we just need to copy variables and parameters from
scope app -> doc  because they are the "doc" variables of this document.

	This is my interpretation of Specification i hope that it is
right. 
	So. I would like the changes in scopes to be clarified in case
of
Root2Leaf And Leaf2Root transition.


VBWG Response: Accepted.

We have clarified in Section 5.1 of [5] that: "Note that while executing

inside the application root document document.x is equivalent to 
application.x.". 


OTHER
	
	Thes are copys of old mail sent to this mail forum, so if you
already have read them  you can skip the rest, unless you allready
skipped
the whole mail.
	They contain some ideas and questions that specification raised.

[4] LINKS (CHOICES) AND CATCHES
	As specified the <link> element ( also <choice> ) has three
attributes that are derived from other components ( or should I say
shorthand ) , event next and expr so:

	<link dtmlf="0" next="something" />
	<link dtmlf="0" expr="'something'+'something'" />
	<link dtmlf="0" event="help" />

	They could be implemented as 

	- The first 2 cases:
	<link dtmlf="0">
		<goto next="something"/>
	</link>
	or	
	<link dtmlf="0">
		<throw event="help"/>
	</link>

	I think that this would be more clear what happens. and would
make
it possible to use <submit> too. In <choice> elements this could be
little
tricky, but would work also. This approach would make it possible to
support
<log> tag inside link too. 

	And what it comes to links it seems to me that they share lots
of
common with catches - they catch an invocation to their grammar and
process
throw or goto .. almost like	
	<catch grmr="link1_grmr">
		<goto next="something"/>		
	</catch>
	or
	<catch event="link1_grmr">
		<goto next="something"/>		
	</catch>
	
	Cause in link it is only needed to know what grammar triggered.
So
catch and link are special cases of catch ?

	Another thing is <prompt> , and to me it is a Big thing :)  I
would
like to know why it is permitted to write "prompts"  without proper
tagging.
I personally think that this wouldn't change the way how pages are made
radically if <prompt>- tags would be mandatory; It would clarify the
content
quite a much.


VBWG Response: Rejected.

While you are correct that there are similarities between <link> and
<catch>, 
<linl> is a simplified form and we want to keep it as simple as
possible. If you want to do more powerful things with a <link>, then you
can use a document-scope <form> instead. 
	
[5] PROMPT ( AND EVENT ) COUNTING
	
		--> Taken form W3C VoiceXML 2.0 draft
	in chapter 4.1.6
	"Each form item and each menu has an internal prompt counter
that is
reset to one each time the form or menu is entered. Whenever the system
uses
a prompt, its associated prompt counter is incremented. This is the
mechanism supporting tapered prompts."
	So the question is : 
	Are prompt counts maintained for <form/> and <menu/> elements
only
or are they maintained for each <*form item*> - specified in chapter
2.1.2
?
	 If we are working like in events; Counters are reset when
entering
<form/> or <menu/>  and we have individual counter for each <*form
item*> ,
but initial uses <form/>s counters. This is right? 
	So does this mean that when  <goto item="this" /> occurs in
field
"that" while field "this" has prompt counter 3 the prompt that has count
3
is selected. So entering <field name="this">..</field> does not reset
counter.
	So returning to  <*form item*> that has prompted something
before
maintains <*form item*>s prompt count and allows us to do "tapered
prompting", yeah ? 

VBWG Response: See response to [1] above.

Received on Tuesday, 29 October 2002 17:44:27 UTC