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.

Scott

Dialog Team Leader, VBWG

[request discussed ...]

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 ?

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