Re: SCXML: <send> and <event>

Jim,

Here's a very simple example that illustrates parts of my previous
suggestion - in particular the part you asked about - but which
despite its simplicity also places new demands on the specification:

 <scxml initialstate="echo">

    <state id="echo">
       <transition event="quit" target="stopped"/>
       <transition event="*">
          <send event="_event.name" expr="_event.data"/>
       </transition>
    </state>

    <final id="stopped"/>

 </scxml>

Now, given a commandline SCXML interpreter capable of reading textual
representations of events from stdin and writing textual
representations of events to stdout, we might imagine it run like so:

 c:/> scxml echo.scxml
 > e1(<a>foo</a>)
 e1(<a>foo</a>)
 > e2(<a><b>foo</b><b>bar</b></a>)
 e2(<a><b>foo</b><b>bar</b></a>)
 > quit
 c:/>

Note that the example also presupposes that:

1. you can get hold of not only the event data but also the event
_name_ in an action
   (I have suggested that this should be possible in a previous mail.)

2. <send> has an attribute 'expr' that may be used to 'forward' the event data


- Torbjörn


On 5/15/07, Barnett, James <James.Barnett@aspect.com> wrote:
> Torbjorn,
>   That's an interesting suggestion.  What would the default behavior be for <send> in m0? What should <send event="e"> mean in m0?
>
> - Jim
>
> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Torbjörn Lager
> Sent: Tuesday, May 15, 2007 12:29 PM
> To: www-voice@w3.org
> Subject: SCXML: <send> and <event>
>
>
> Hi All,
>
> Based on my attempts (soon to be released in Synergy SCXML-Lab) to
> make <send> and <event> behave more in accordance with the current
> draft, I have come up with couple of suggestions that deviate somewhat
> from what is said in the draft. Nothing radical, just a few small
> things.
>
> Suppose that we have three machines m0, m1 and m2, where m0 has
> invoked m1 and m1 has invoked m2 (m0 may in fact be the runtime
> environment of the SCXML interpreter, e.g. the OS), and that we are
> executing a <send> in m1. In my understanding of the current
> specification here's how we
>
>  1. add "e" to the external queue of m0:
>
>     <send event="e" target="'m0'"/>
>     <send event="e" target="_caller"/>
>
>  2. add "e" to the external queue of m1:
>
>     <send event="e"/>
>     <send event="e" target="'m1'"/>
>     <send event="e" target="_self"/>
>
>  3. add "e" to the external queue of m2:
>
>     <send event="e" target="'m2'"/>
>
>  4. add "e" to the internal queue of m1:
>
>     <event name="e"/>
>
> Based on my experiences implementing an playing with this, I have a
> couple of comments:
>
> 1. My first comment is simply terminological. I think the term
> "external queue" is confusing. I would much prefer the term "input
> queue" instead, which more clearly describes its role.
>
> 2. I think the draft gets the default for 'target' wrong. In my view
> it makes more sense to make '_caller' the default here, since
> returning events from an invoked machine to an invoking machine (which
> could be the runtime environment of the SCXML interpreter) is probably
> a common thing to do, and, as far as I can see, a machine adding
> events to its own *external* queue probably isn't very common. (It is
> of course important for a machine to be able to add events to its own
> *internal* queue.)
>
> 3. As I have said in an earlier name, I don't think "event" (as in
> <event>) is a good name for a piece of executable content. I'm
> suggesting using "raise" instead, with an attribute 'event', in
> analogy with <send>.
>
> So, here's how I suggest it should work. In m1, to
>
>  1. add "e" to the input queue of m0:
>
>     <send event="e"/>
>     <send event="e" target="'m0'"/>
>     <send event="e" target="_caller"/>
>
>  2. add "e" to the input queue of m1:
>
>     <send event="e" target="'m1'"/>
>     <send event="e" target="_self"/>
>
>  3. add "e" to the input queue of m2:
>
>     <send event="e" target="'m2'"/>
>
>  4. add "e" to the internal queue of m1:
>
>     <raise event="e"/>
>
>
> Regards,
> Torbjörn
>

Received on Wednesday, 16 May 2007 05:25:00 UTC