W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2010

Re: Dialog and Connection semantic error handling

From: Petr Kuba <kuba@optimsys.cz>
Date: Fri, 07 May 2010 16:16:46 +0200
Message-ID: <4BE420CE.7020107@optimsys.cz>
To: Chris Davis <davisc@iivip.com>
CC: www-voice@w3.org

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 event="dialog.prepared" >
       <dialogstart prepareddialogid="event$.dialogid"
                    connectionid="'fake_conn_id'" />

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 

     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.


    Petr Kuba, Project Manager
    OptimSys, s.r.o
    Tel: +420 541 143 065
    Fax: +420 541 143 066

> 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 Friday, 7 May 2010 14:17:26 UTC

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