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: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 12 Feb 2009 23:48:36 +0900
Message-ID: <499436C4.1040702@w3.org>
To: RJ Auburn <rj@voxeo.com>
CC: Neil.Boxall@generaldynamics.uk.com, rajeshn@huawei.com, www-voice@w3.org

I think Neil is registered with www-voice :)

Kazuyuki


RJ Auburn wrote:
>
> Neil:
>
> Are you a member of the w3c working group or www-voice?
>
>     RJ
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
>
> On Feb 12, 2009, at 9:06 AM, <Neil.Boxall@generaldynamics.uk.com> wrote:
>
>>
>> All,
>>
>> For some strange reason, I am being blind copied on some e-mails as
>> below. Please could Voxeo check this.
>>
>> Thanks,
>>
>> NB
>>
>>
>> -----Original Message-----
>> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
>> Behalf Of RJ Auburn
>> Sent: 12 February 2009 13:25
>> To: rajeshn@huawei.com
>> Cc: www-voice@w3.org
>> Subject: Re: Regarding posting ccxml.exit to parent upon child getting a
>> ccxml.kill event - ISSUE-569 [cc]
>>
>>
>> Rajeshn,
>>
>> This is being tracked as ISSUE-569.
>>
>> Thanks,
>>
>>     RJ
>>
>> ---
>> RJ Auburn
>> CTO, Voxeo Corporation
>> tel:+1-407-418-1800
>>
>> 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
>>>
>>
>>
>>
>> This email and any files attached are intended for the addressee and 
>> may contain information of a confidential nature. If you are not the 
>> intended recipient, be aware that this email was sent to you in error 
>> and you should not disclose, distribute, print, copy or make other 
>> use of this email or its attachments. Such actions, in fact, may be 
>> unlawful. In compliance with the various Regulations and Acts, 
>> General Dynamics United Kingdom Limited reserves the right to monitor 
>> (and examine for viruses) all emails and email attachments, both 
>> inbound and outbound. Email communications and their attachments may 
>> not be secure or error- or virus-free and the company does not accept 
>> liability or responsibility for such matters or the consequences 
>> thereof.  General Dynamics United Kingdom Limited, Registered Office: 
>> 100 New Bridge Street, London EC4V 6JA. Registered in England and 
>> Wales No: 1911653.
>
>


-- 
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@w3.org
voice: +81.466.49.1170 / fax: +81.466.49.1171
Received on Thursday, 12 February 2009 14:49:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 February 2009 14:49:21 GMT