RE: SCXML: <invoke> etc.

Torbjorn,
  One further comment on <invoke>.  You mention below that allowing multiple <invoke> tags in one state would rule out letting the state's ID serve as the ID of the invoked component.  It is not completely correct to use the state ID even in the current implementation, and you will note that the algorithm requires the generation of a unique ID for each invocation.  

The reason for this is the following example (which someone else pointed out to us):  suppose state S1 contains an <invoke> tag and the system enters S1 and then leaves and re-enters it rapidly.  When the system leaves S1, it must cancel the ongoing invocation, but it is always possible that the cancellation message could cross paths with the response "S1.done" from the invoked component.  So if the system receives "S1.done" right after firing the <invoke> on its second entry into S1, it does not know which invocation the event is a response to - if the "S1.done" was sent as the result of the first invocation, it should be ignored, should not trigger <finalize> processing and not added to the event queue, but if it was sent as the result of the second invocation, it should trigger <finalize> and be added to the event queue.  

I don't know how likely this sequence of events is in practice, but it strikes me as logically compelling, which is why the current algorithm requires that a unique ID be generated and tracked.  (Note that the unique ID is distinct from the state ID, but can be mapped to it and that processing in Wait_External_Event_Phase and Exit_State_Phase checks for an ID match.)  Of course, there could well be a bug in our logic somewhere, but if so I'm sure you'll find it...

- 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 20:28:48 UTC