On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> 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. -Rahul
Craig
