Response to dialog request R426

Your request (R426) for clarification for application developers
(reproduced below) was discussed by the Dialog team on 2002-05-07. We
believe that this issue may have been addressed in the latest draft (or
responses to other requests from you). 

If you think we still need to address your issues, please let us know as
soon as possible. If we do not hear from you with 14 days, we will take
this as tacit acceptance.

thank you for input on the specification.


Dialog Team Leader, VBWG

[request discussed ...]


As Jean-Michel Reghem [] 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
point of view  This makes it difficult to application developer to
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.
is out from this discussion cause it already is quite difficult for
application developer.

In field elements  <field> <initial> event thrown in collect phase (
event "nomatch" ) prevents field to be filled unless otherwise assigned
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,
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
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
element. because it anyways causes FIA to exit. So should the field
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
again <subdialog> elements cond change or <assign> to fill the field ,
in <field>, could be used.

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

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

This comes much about the underlying system but I think that if there
something recorded on underlying layer ( in here we have to think
detection etc. systems ) and then hang-up ,  the collection phase in
"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
already brought it up I think that field gets filled only if event is
thrown in collection phase. < form> level <catch> will handle this quite

The field elment <transfer> is like <field> to me. Should it be ( so in
of blind transfer )  the event is handled and field is not filled.
Hopefully that <catch> does the <exit/> or similiar. Is this the case
<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
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.


VXML 2.0 draft introduces more transitions within document, and some of
these are not clearly explained. I would like to have some
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
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
( in spec Root2Root; "The root context is initialized with the new
application root document, even if the documents are the same or have
same application name" ) so should variables ( and parameters ) in scope
application be identical ( application == document ). ok.  lets keep it
way. Should there be variables in scope application at all ? 
	In Step 2. The doc scope should be replaced with variables for
doc 2. Right because this is the "doc" that we are executing .  Yep This
	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
	So. I would like the changes in scopes to be clarified in case
Root2Leaf And Leaf2Root transition.

	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
the whole mail.
	They contain some ideas and questions that specification raised.

	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 dtmlf="0">
		<throw event="help"/>

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

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

	Another thing is <prompt> , and to me it is a Big thing :)  I
like to know why it is permitted to write "prompts"  without proper
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
quite a much.
		--> 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
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
or are they maintained for each <*form item*> - specified in chapter
	 If we are working like in events; Counters are reset when
<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
"that" while field "this" has prompt counter 3 the prompt that has count
is selected. So entering <field name="this">..</field> does not reset
	So returning to  <*form item*> that has prompted something
maintains <*form item*>s prompt count and allows us to do "tapered
prompting", yeah ? 

Received on Tuesday, 28 May 2002 09:30:41 UTC