- From: Petr Kuba <kuba@optimsys.cz>
- Date: Mon, 06 Sep 2010 13:43:40 +0200
- To: Baggia Paolo <paolo.baggia@loquendo.com>
- CC: "'www-voice@w3.org'" <www-voice@w3.org>
Paolo, Thanks for you clarification. This is acceptable for us. Regards, Petr On 3.9.2010 16:00, Baggia Paolo wrote: > Petr, > > your examples is very useful, but we consider this assertions to > be verified upfront in (1) to generate error.semantic and avoid > the generation of Dialog Object. > > While a valid connid that disconnect in the meantime will result > in error.dialog.notstarted when the dialog Object is present. > > Paolo. > > -----Original Message----- > From: Petr Kuba [mailto:kuba@optimsys.cz] > Sent: venerd́ 3 settembre 2010 11.42 > To: Baggia Paolo > Cc: 'www-voice@w3.org' > Subject: Re: Dialog and Connection semantic error handling [cc] ISSUE-692 > > Paolo, > > Please find my comments in-line. > > On 2.9.2010 10:02, Baggia Paolo wrote: >> Petr, >> >> The general concept is: an element which generates an error.semantic - either blocking or non-blocking - in general DOES NOT produces any effect, i.e. it has to be considered not executed. This means that, from the point of view of ECMA objects, it does not change them, and it does not create them if they do not exist. >> >> Examples: if a Connection Object exists for a given connection, and an element which should change its state generates an error.semantic, the state won't be changed. In the same way, if a correct<dialogprepare> creates a Dialog Object and after that there's a<dialogstart> which generates an error.semantic, that Object is not affected by the dialogstart command. BUT (and this is the case of the test under discussion by this issue) if the dialostart should create the Object (because there wasn't any dialogprepare before) and it generates an error.semantic, its effect of creating the Object DOES NOT take place, and the object is never created. > I believe that this example with<dialogstart> after<dialogprepare> is > very important. It means that if<dialogstart> results in error.semantic > it is allowed to run<dialogstart> again, am I right? I'm not sure > whether this is clear enough in the specification. > >> You are right, the spec says: >> "Execution of a<dialogprepare> or<dialogstart> without preparation creates a Dialog Object immediately, allowing the Dialog Object to be accessed following the<dialogprepare>/<dialogstart>, within the same transition." >> >> but only if the element is really executed to especially cover the presence of a Dialog Object after a dialogprepare, while in the case of error.semantic it shouldn't. In case of non-blocking error, the execution continues after the wrong element, but this does not mean that that element is correctly and completely executed. >> > This sounds clear in theory but problems appear during implementation. > For instance, in our implementation<dialogstart> (without previous > <dialogpreapre>) is executed as follows: > > 1) All<dialogstart> parameters are evaluated. In case of an ECMAScript > error error.semantic is thrown and the execution is interrupted. > (Everything is OK here). > 2) Dialog interpreter is started (it is asynchronous) and it handles all > other operations in its own thread > 3) EHIA algorithm continues to interpret next element within the same > transition. > > We have to create a Dialog Object in step (2) because it must be > available in (3). On the other hand there is no reason to blok the EHIA > algorithm in (2) until the Dialog interpreter is started -<dialogstart> > operation is asynchronous and must not block. > > If there is connectionid specified in<dialogstart> then the join > operation is performed during the Dialog interpreter startup, i.e. it is > asynchronous. Thus it can happen that the join is performed even after > (or during) step (3). So this is the moment where we find out that the > referenced connection is invalid (e.g. it was disconnected between steps > (1) and (3) ) and we should throw error.semantic. The problem is that > the Dialog Object already exists. > > It probably doesn't help to check validity of the connection in (1) > because it can be terminated in the meantime and<dialogstart> will not > execute completely anyway. > > My question is how to handle this situation: > - we have to create a Dialog object in (2) > - the join operation during dialog startup is asynchronous and > error.semantic must be thrown in case of invalid connection > - you say that the Dialog object must not be created in case of > error.semantic > > It sound contradictory to me. And I don't thing the clarification below > solves this problem (although it is useful for sure). > > Do I miss something? > > Regards, > Petr > > >> If you think a clarification might be added to the specification, for example: >> "Execution of a<dialogprepare> or<dialogstart> without preparation creates a Dialog Object immediately, allowing the Dialog Object to be accessed following the<dialogprepare>/<dialogstart>, within the same transition. [[[ If the execution of the elements generates an error.semantic, the Dialog Object is not created.]]]" >> >> The same should be added in 10.2.4: >> >> The spec says: >> "The sole exception to this is<createcall>, which creates a Connection Object immediately, with its 'state' property set to CREATED, allowing the Connection Object to be accessed following the<createcall>, within the same transition." >> >> This sentence might be added as well: >> If the execution of the element generates an error.semantic, the Connection Object is not created. >> >> But the general rule has to be: if an error semantic occurs, the element which generates the error is not really executed, so it has no effect whatsoever. >> >> lease 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, >> Paolo >> ---------------------------- >> From: Petr Kuba<kuba@optimsys.cz> >> Date: Mon, 30 Aug 2010 11:59:28 +0200 >> Message-ID:<4C7B8100.20408@optimsys.cz> >> To: RJ Auburn<rj@voxeo.com> >> CC: Chris Davis<davisc@iivip.com>, www-voice<www-voice@w3.org> >> >> RJ, >> >> Thanks for the clarification. >> >> >> However, regarding<dialogstart>, the following text in 7.1 must be >> also considered: >> >> "Execution of a<dialogprepare> or<dialogstart> without preparation >> creates a Dialog Object immediately, allowing the Dialog Object to be >> accessed following the<dialogprepare>/<dialogstart>, within the same >> transition." >> >> Please consider the following scenario: >> >> <dialogstart ... connectionid="'fake_conn_id'"/> >> >> There is no ECMAScript evaluation error but the element references an >> invalid connection which causes the platform to raise NON-BLOCKING >> error.semantic. >> >> I assume that the error.semantic event is raised asynchronously during >> dialog initialization. This means that the Dialog Object already >> exists when the error is thrown. >> >> Do I miss something? >> >> Regards, >> Petr >> >> >> RJ Auburn wrote: >>> 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 Monday, 6 September 2010 11:44:46 UTC