Re: Dialog and Connection semantic error handling [cc] ISSUE-692

Petr:

This is being tracked as ISSUE-692
---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

Come join us at our Voxeo Customer Summit
June 21st – June 23rd at the Hard Rock Hotel
Register today for your All Access Pass:  
http://www.voxeo.com/summits/customer




On May 7, 2010, at 10:16 AM, Petr Kuba wrote:

> Chris,
> 
> Thanks for your response. Please find my comments below.
> 
> On 7.5.2010 15:26, Chris Davis wrote:
>> Peter,
>> 
>> Our SPOT browser would queue up an error.semantic in your examples of
>> "fake_conn_id"
>> because section 9.3.2 says error.semantic is appropriate when "passing
>> an invalid value for an attribute."
> 
> OptimTalk would behave exactly the same way but I still believe that the specification could be more precise.
> 
> It's clear that "passing an invalid value for an attribute" covers the following error (fake_variable is not declared):
> 
>    <dialogstart ... connectionid="fake_variable"/>
> 
> but does it also cover this one (the attribute value is a correct string but there is no connection with this id)?
> 
>    <dialogstart ... connectionid="'fake_conn_id'"/>
> 
> I believe yes and the following statement in 9.1 confirms that:
> 
>    Note that while an element that references an invalid connection,
>    dialog, or conference identifier also causes the platform to raise
>    error.semantic, these scenarios MUST NOT terminate execution of the
>    <transition> in which that element is contained.
> 
> Nevertheless, I think that it would be useful to mention this explicitly in the connectionid attribute description (and in all analogous situations, of course).
> 
> 
>> 9.3.2 is a bit of a "catch all" because other tags often define specific
>> error events they want to see
>> for invalid attributes such as <send>'s error.send.targettype.
>> 
>> For a <dialogstart> error, SPOT assumes no dialog is created in an error
>> condition because by definition
>> the request has failed. I can't think of a rational use for failed
>> dialogs to an application developer. It seems
>> to us either it got created ok and exists, or there was an error and no
>> dialog exists.
> 
> Again, I agree with you: there is no reason to continue with a "corrupted" dialog. However, consider the following code:
> 
>    <transition event="ccxml.loaded" >
>      <dialogprepare src="'example.vxml'"/>
>    </transition>
> 
>    <transition event="dialog.prepared" >
>      <dialogstart prepareddialogid="event$.dialogid"
>                   connectionid="'fake_conn_id'" />
>    </transition>
> 
> In this case, dialog is prepared correctly and Dialog Object is created in session.dialogs immediately in <dialogprepare> (according to the April CCXML).
> 
> Then error.semantic is thrown in <dialogstart>. My question is when the Dialog Object should be removed from session.dialogs. In normal situations, the Object is removed after the dialog.exit or error.dialog or a similar event is delivered and processed.
> 
> So the question is whether the Object should be removed as a result of the error.semantic event delivery. Probably yes but it should be stated in the spec. On the other hand, it breaks the following statement in 10.2.4 (provided that we expect the same behavior for connections and dialogs):
> 
>    The error.semantic event MUST NOT change the state of the
>    associated Connection Object(s).
> 
> To me, it sounds a little bit unsystematic that a "general" event like error.semantic modifies the state of a dialog or connection.
> 
> Regards,
> Petr
> 
> -- 
>   Petr Kuba, Project Manager
>   OptimSys, s.r.o
>   kuba@optimsys.cz
>   Tel: +420 541 143 065
>   Fax: +420 541 143 066
>   http://www.optimsys.cz
> 
> 
> 
>> Regards,
>> Chris
>> 
>> Petr Kuba wrote:
>>> Hello,
>>> 
>>> Could you please clarify the following issues?
>>> 
>>> Description of the connectionid attribute of the <dialogstart> element
>>> states:
>>> 
>>> If the attribute value is invalid an error.semantic event must be
>>> thrown.
>>> 
>>> The question is whether this statement applies only to ECMAScript
>>> errors such as accessing non-declared variable or also to the case
>>> where unknown connection is referenced. For example:
>>> 
>>> <dialogstart ... connectionid="'fake_conn_id'"/>
>>> 
>>> Value of connectionid will be evaluated correctly in this case but
>>> there is no connection with the given id. Shall error.semantic be
>>> thrown in this case?
>>> 
>>> Another question is what shall be done when error.semantic is thrown
>>> when executing <dialogstart>. Is it allowed to call <dialogstart>
>>> again, shall <dialogterminate> be called, or shall the Dialog Object
>>> be destroyed automatically?
>>> 
>>> Please note that these questions apply also to <dialogprepare> and
>>> connection-related elements and the following statement is related to
>>> this issue:
>>> 
>>> 10.2.4: Connection Operations
>>> 
>>> If the element cannot be evaluated, for example if the referenced
>>> connectionid contained an invalid ECMAScript expression, then an
>>> 'error.semantic' event is thrown - as is the case for all CCXML
>>> elements. The error.semantic event MUST NOT change the state of the
>>> associated Connection Object(s).
>>> 
>>> So if the dialog behaves the same way as connection it should not be
>>> destroyed automatically after error.semantic.
>>> 
>>> Thanks for clarification,
>>> Petr Kuba
>>> 
>> 
>> 
>

Received on Thursday, 13 May 2010 14:52:47 UTC