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

Re: Comments on CCXML Working Draft 19 January 2007 (2) - ISSUE-232 [cc]

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 27 Mar 2008 08:07:27 -0400
To: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr>
Message-Id: <A2F77AC0-B5ED-48CD-BA7E-752283B1AC9D@voxeo.com>
Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>

Hrvoje,

Since we have not heard back from you on this issue we are going to  
assume that this resolution is acceptable to you. Thank you very much  
for your comments on the CCXML specification.

Best regards,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800



On Jan 31, 2008, at 10:09:44, RJ Auburn wrote:
>
> Hrvoje,
>
> We have actually added some new text to the CCXM spec around error  
> handing. Here is a snippet of it:
>
>> Once selected, an object representing the event being processed is  
>> created at transition scope, and the elements inside the  
>> <transition> are executed in document order. If ECMAScript  
>> evaluation errors occurs during the execution of an element within  
>> a transition, then successive elements within that transition MUST  
>> NOT be executed; an error.semantic MUST be raised for the element  
>> whose attributes could not be evaluated. Note that errors caused by  
>> failures in the execution of an element (such as a <disconnect> on  
>> an invalid connection ID), including any that generate an  
>> ERROR.SEMANTIC event, MUST NOT terminate execution of the transition
>>
>
> Our feeling is this should resolve your questions around the error  
> handing. Please let us know if this resolves the issues for you by  
> Feb 22nd 2008. If we do not hear from you by that date we will  
> consider the issues closed.
>
> Thank you very much for your comments on the CCXML specification.  
> These have helped improve the specification and the entire working  
> group greatly appreciates your assistance.
>
> Best regards,
>
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
>
>
>
> On Feb 8, 2007, at 10:25:36, RJ Auburn wrote:
>
>>
>> This is being tracked as ISSUE-108
>>
>> 	RJ
>> ---
>> RJ Auburn
>> CTO, Voxeo Corporation
>> tel:+1-407-418-1800
>>
>>
>>
>> On Feb 7, 2007, at 6:19 AM, Hrvoje Nezic wrote:
>>
>>>
>>> 9: Event handling
>>>
>>> Current text:
>>> "If a semantic error occurs that prevents an element in the  
>>> transition from being executed (such as the 'cond' attribute of  
>>> <if> being an invalid ECMAScript expression), then successive  
>>> elements within that transition will NOT be executed; an  
>>> error.semantic will be raised for the element that could not be  
>>> executed. Note that elements that can be executed but that  
>>> generate errors (such as a <disconnect> on an invalid connection  
>>> ID) do not terminate execution of the transition."
>>>
>>> I think that this explanation is not clear enough. The phrase  
>>> "elements that can be executed but that generate errors" could be  
>>> applied to most CCXML elements. I think that intention was  
>>> probably to distinguish between synchronous and asynchronous  
>>> elements. Synchronous elements are <var>, <assign>, <script>,  
>>> <if>, <elseif>, <else>, <goto>, <exit>, <log>, while other  
>>> elements are asynchronous and generate events to signal success or  
>>> failure.
>>>
>>> The new text could be something like this:
>>> "If a semantic error occurs that prevents a synchronous element in  
>>> the transition from being executed (such as the 'cond' attribute  
>>> of <if> being an invalid ECMAScript expression), then successive  
>>> elements within that transition will NOT be executed; an  
>>> error.semantic will be raised for the element that could not be  
>>> executed. If a semantic error occurs that prevents an  
>>> asynchrounous element from being executed (such as a <disconnect>  
>>> on an invalid connection ID), execution of the transition will not  
>>> be terminated."
>>>
>>
>>
>
>
Received on Thursday, 27 March 2008 12:08:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 March 2008 12:08:54 GMT