Suggestions for the clarification needed to make VXML 2.0 easier to understand for Application developers

Dear Colleagues. 

I want to open a discussion about few clarification needed to make into
coming versions of the VXML 2.0. 

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.

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.

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.

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.
	
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 ? 
	
Sincerely
	Teemu Tingander ( teemu@tecnomen.fi )
	Innovation Centre
	Tecnomen Oyj
	Finland

Received on Thursday, 7 February 2002 02:50:18 UTC