RE: SCXML: <invoke> etc.

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:13:23 UTC