shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Submachines, Contexts and Shale subdialogs (was Re: Get rid of subdialogs)
Date Thu, 24 Aug 2006 22:37:37 GMT
On 8/24/06, Rahul Akolkar <> wrote:
> [snip]
> Which brings us to the discussion about sharing "dialog data" as-in
> SHALE-153, and this is where Shale subdialogs deviate from most
> dialects of state chart theory, where submachine states are not
> processed according to the stack-based GOSUB approach WRT state
> contexts. A submachine state is meant to be "syntactic sugar" and
> should not have any difference in (runtime) semantics as compared to
> inlining the submachine into the parent state machine. And that tends
> to blow away any concerns about sharing data / communicating across
> parent-child (sub)dialogs.
> i.e. if foo.scxml from the snippet above pointed to this degenerate
> machine:
> <scxml initialstate="end">
> <state id="end" final="true" />
> </scxml>
> the original state above may be replaced by the following:
> <state id="foo" ...>
> <initial>
>   <transition target="end"/>
> </initial>
> <state id="end" final="true" />
> ...
> </state>
> for identical behavior. Commons SCXML will "crawl" to the src URL,
> grab the state machine from foo.scxml, parse and incorporate it into
> the parent state machine as the state holding the src attribute. The
> "root context" of foo.scxml then becomes the context for the state
> with id "foo".

So, to see if I'm getting it yet, are the following statements an accurate
representation of what you're describing?

* SCXML achieves reuse by essentially "inlining" a previously
  configured set of descriptions into the current one; and

* When that happens, there is only one "context" instead of the
  stack that Shale Dialog currently creates when you use
  a subdialog.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message