W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2009

Re: Regarding posting ccxml.exit to parent upon child getting a ccxml.kill event - ISSUE-569 [cc]

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 12 Feb 2009 08:25:04 -0500
Cc: www-voice@w3.org
Message-Id: <22BBF9EE-03E0-4716-B54B-24ABBD5BD390@voxeo.com>
To: rajeshn@huawei.com


This is being tracked as ISSUE-569.



RJ Auburn
CTO, Voxeo Corporation

On Feb 9, 2009, at 9:03 PM, Rajesh N wrote:

> Hi,
> I have a doubt regarding the ccxml.exit event posted to the parent  
> session when the child session ends.
> The spec says.. "This event is generated when a CCXML document  
> executes an <exit>, having an unhandled "error.*" or ccxml.kill event"
> From my interpretation of this sentence and the subsequent  
> explantion of the "reason" attribute, I find three possibilities for  
> child session to terminate:
> a) Child session encounters an <exit> element in any transition  
> (normal event / error event / kill event)
> b) Child session recieves an(y) error event (error.*), but there is  
> no transition to handle it.
> c) Child session recieves a ccxml.kill event.
> My doubt is regarding option (c) above. There are 3 sub- 
> possibilities for this case:
> (i) Child session has a transition to handle to ccxml.kill event and  
> the transition also has an <exit> element. Event handling results in  
> the processing of <exit>.
> (ii) Child session has a transition to handle to ccxml.kill event,  
> BUT the transition DOES NOT have an <exit> element.
> (iii) Child session DOES NOT have a transition for ccxml.kill event
> The child session should terminate in all these cases. Should  
> ccxml.exit be posted to parent session in all these cases?
> The basic reason for this doubt  is a small level of ambiguity  
> associated with the phrase "having an unhandled "error.*" or  
> ccxml.kill event". Does the "unhandled" apply to only error.* or  
> both error.* and ccxml.kill?
> Please clarify.
> Thanks
> Rajesh
Received on Thursday, 12 February 2009 13:26:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:55 UTC