Re: SCXML: <invoke> etc.

Jim,
Thanks again for the clarifications! I think I now see the subtle 
differences, although I must admit that I cannot for the moment imagine 
any usecases where the differences would matter. And when you write:

 > In this it is different from the targetless transition alternative - 
if the targetless transition is selected,
 > no other transition will be triggered by that event (except in the 
case of parallel states).

I guess my response would be that the targetless transition could use 
<send> to 'forward' a modifed version of the event in question - and 
event that could trigger these other transitions. (In my own 
implementation, I have added an 'expr' attribute to <send> that makes 
this very straightforward.) But I agree that, on the whole, this is less 
appealing...

I totally agree that events as such should be readonly !

Cheers,
Torbjörn

> Torbjorn,
>   The role of finalize is subtle and I hope to clarify it in a future draft.  The important thing is that it applies _before_ any transitions are selected and does not _replace_ the transitions.  In this it is different from the targetless transition alternative - if the targetless transition is selected, no other transition will be triggered by that event (except in the case of parallel states).   
> <finalize> is intended to allow normalization and updating the data model with the data returned, but NOT of the event itself.  There's a clause in Section 11 that specifically prohibits the modification of the event itself.  It seems to me that semantic chaos would ensue if we allowed events to be modified during the course of processing - suppose we have two transitions that are triggered by events "foo" and "bar" respectively.  Now suppose event "foo" occurs.  Now we select the transition that is triggered by "foo", and the first thing its executable content does is to change the name of the event to "bar" - for the rest of that transition and the onentry handlers of the target state, etc., it will look like we took the wrong transition.  Ugly.
>
> We already have an internal request to allow multiple <invoke> instances and to allow them in non-atomic states, so we will revisit this issue at some point.  
>
> - Jim
>
> -----Original Message-----
> From: Torbjörn Lager [mailto:lager@ling.gu.se] 
> Sent: Thursday, May 10, 2007 11:01 AM
> To: www-voice@w3.org
> Cc: Barnett, James
> Subject: Re: SCXML: <invoke> etc.
>
> Jim,
>
> Thanks for the prompt response! Your explanation confirmed one of the 
> readings I had of the current specification of <invoke> - and I do find 
> this reading very reasonable. However, there are still passages that 
> confuses me, in particular passages dealing with <finalize>.  I do 
> understand _one_ role that <finalize> is supposed to have: to update the 
> datamodel in the invoking machine with values returned in events coming 
> from the invoked machine. But it appears to me that this role could 
> equally well be filled by (possibly targetless) transitions from the 
> state in which the <invoke> is embedded. That is, instead of:
>
>  <state ...>
>     <invoke ...>
>        <finalize>
>           ... exec. content ...
>        </finalize>   
>     </invoke ...>
>  </state ...>
>
> we could have:
>
>  <state ...>
>     <invoke .../>
>     <transition ...>
>        ... exec. content ...
>     </transition ...>
>  </state ...>
>
> Or am I missing something?
>
> There are some passages that seem to suggest that <finalize> could have 
> another role as well. In section 6.1:
>  "The finalize code can thus be thought of as a preprocessing stage that 
> applies before the event is added to the event queue."
>
> Also, in section 6.1.2:
>  "<finalize>. Optional element containing executable content to massage 
> the data returned from the invoked component. ..."
>
> The wording here makes it sound like <finalize> is able to _change_ an 
> event returned from the invoked machine - to transform it into another 
> form - before it 'leaves' the <invoke> element. Do you have something 
> like this in mind as well? I think that the idea of <finalize> as a kind 
> of "event translator" or "data transformer" - has a certain appeal to 
> it. There may be situations where a developer decides to invoke 
> something which generates some events that just aren't useful, or even 
> harmful, and that he would like to stop before the rest of the machine 
> can see them. And there may be events that he wants to transform into 
> another form. On the other hand, this could be done by means of 
> transitions as well - transitions that catch the events in question 
> before they go any further, and that possibly also send new events, with 
> data payloads based on computations involving the original events.
>
> This would then reduce the <finalize> element to "syntactic sugar", 
> wouldn't it? (I have nothing against syntactic sugar - I'm all for it - 
> but the specs should then clearly state that it *is* sugar, and provide 
> a translation into the 'kernel language'.)
>
> Another thing: It seems to me that you could allow states to have more 
> than one <invoke> child, and that this might be very useful. (This is 
> however not compatible with the idea of letting the state´s ID serve as 
> the ID of the invoked component, but that could presumably be handled in 
> another way.)
>
> Regards,
> Torbjörn
>
>
>
>
>
>
>
>
>
> Barnett, James wrote:
>   
>> Torbjorn,
>>  The chances of us being last call in September are 0, (in part because of all the problems you're helping us discover.)  The next draft will most likely not be Last Call, but I don't know when it will be out. 
>>
>> I agree that the <invoke> section needs tightening up, but in any case the intent is that the invoked machine shares _nothing_ with the invoking one - the only communication between the two state machines is via data a) passed in <param>, b) explicitly sent in <send> elements or c) returned (in a platform-specific way upon the exit of the invoked machine).  So the event queue should not be shared.  
>>
>> Given clause b above, you probably do want to set up some sort of mechanism whereby the invoked machine can <send> events back to the invoking machine, and vice versa.  (When you do this, you will notice another gap in the spec, which is that there is no way for the author to get access to the SCXML session ID, which you will need when communicating between machines that are each running multiple sessions - we will fix this in the next draft of the spec.)
>>
>> - Jim 
>>
>> -----Original Message-----
>> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Torbjörn Lager
>> Sent: Thursday, May 10, 2007 8:12 AM
>> To: www-voice@w3.org
>> Subject: SCXML: <invoke> etc.
>>
>>
>> Hi,
>>
>> The specification of <invoke> and related elements is quite vague and 
>> ambiguous in the current draft. In my current implementation (at 
>> <http://www.ling.gu.se/~lager/Labs/SCXML-Lab/>), if an SCXML state 
>> machine invokes (e.g.) another SCXML state machine, the external queue 
>> of the latter is simply completely shared with the external queue of the 
>> former. This is probably not the way it should be done, and probably not 
>> what you have in mind. Right?
>>
>> I saw that the last call working draft of SCXML is planned in September. 
>> Any chances you could leak something about your current thoughts on 
>> <invoke> etc.- if you have any - before then?
>>
>> Regards,
>> Torbjörn
>>   
>>

Received on Thursday, 10 May 2007 15:42:38 UTC