- From: RJ Auburn <rj@voxeo.com>
- Date: Thu, 26 Aug 2010 11:03:13 -0400
- To: Petr Kuba <kuba@optimsys.cz>
- Cc: W3C Voice Browser Working Group <w3c-voice-wg@w3.org>, Chris Davis <davisc@iivip.com>, www-voice <www-voice@w3.org>
Petr: Here is the reply from the review of ISSUE-692: > I try to reply to ISSUE-692 from Petr Kuba > >> ISSUE-692: PUBLIC - CR - Dialog and Connection semantic error >> handling [CCXML] >> > >> 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? > > The functioning of error.semantic is explained in the spec at 9.1 chapter, 9th paragraph. > There are 2 types of error.semantic, one which blocks the transition and one which does not: > > ----------------- > 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 an ECMAScript evaluation error occurs during the execution of an element within a <transition>, error.semantic MUST be raised for that element, and successive elements within that <transition> MUST NOT be executed; 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. > ---------------- > >> >> 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? >> > > In this case the dialog never started, so it need not to be terminated and the Dialog Object does not exist. > The same applies to <dialogprepare>. > >> 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. >> > > The dialog does not exist if <dialogstart> does not terminate successfully, while a connection does exist even if one operation on that connection causes an error. So if an error occurs, the connection object remains as is, it is not affected by the not successfull operation. Please explicitly confirm that you accept the proposed resolution or after one week we will consider it implicitly accepted. If you need clarifications, please feel free to let us know and we will do our best to resolve them. Best regards, RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 skype:zscgeek On May 13, 2010, at 10:51 AM, RJ Auburn wrote: > 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, 26 August 2010 15:03:46 UTC