RE: SCXML: <invoke> etc.

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 12:28:36 UTC