You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Bill Herring <bh...@openmethods.com> on 2010/01/07 23:51:13 UTC
History in parallel?
My reading of the latest W3C working draft is that SCXML supports
history pseudo-states in parallel ones. When I run my app with the
SCXML model below, I get:
WARNING: Ignoring element <history> in namespace "http://www.w3.org/2005/07/scxml
"
and then it cannot find the two resume_ targets.
Does Commons SCXML support history elements as parallel children? Am
I doing something wrong here?
<?xml version="1.0"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
version="1.0" initial="off_call">
<state id="off_call">
<transition event="dial" target="call_active"/>
</state>
<parallel id="call_active">
<state id="talk_status" initial="talking">
<state id="talking">
<transition event="hold" target="held" />
</state>
<state id="held">
<transition event="retrieve" target="talking" />
</state>
</state> <!-- END talk_status -->
<state id="call_status" initial="on_call">
<state id="on_call">
<transition event="hangup" target="off_call"/>
<transition event="consult" target="consult_active"/>
</state>
<state id="on_call_consult">
<transition event="hangup" target="off_call"/>
<transition event="alternate" target="resume_consult"/>
</state>
</state> <!-- END call_status -->
<history id="resume_call" type="deep"/>
</parallel> <!-- END call_active -->
<parallel id="consult_active">
<state id="consult_talk_status" initial="consult_talking">
<state id="consult_talking">
<transition event="hold" target="consult_held" />
</state>
<state id="consult_held">
<transition event="retrieve" target="consult_talking" />
</state>
</state> <!-- END consult_talk_status -->
<state id="consult_status" initial="on_consult">
<state id="on_consult">
<transition event="hangup" target="resume_call"/>
<transition event="alternate" target="resume_call"/>
</state>
</state> <!-- END consult_status -->
<history id="resume_consult" type="deep"/>
</parallel> <!-- END consult_active -->
</scxml>
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Parallel parent states resetting to initial substates?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Jan 8, 2010 at 6:37 PM, Bill Herring <bh...@openmethods.com> wrote:
> OK, I found that it is indeed a feature (Section 3.3.3 of the SCXML spec),
<snip/>
Yup, followed transition's parent state will always be exited (and if
its the base of an orthogonal region, that means all other orthogonal
region siblings will have to be exited too, given the semantics of
<parallel>).
> but I still need the behavior I describe in my original email. In an
> attempt to fix the problem, I added history states to the two parallel
> parent states, like this:
>
> <parallel id="open_channel">
> <state id="agent_status">
> <initial>
> <transition target="resume_agent_status"/>
> </initial>
> <transition event="tester.Pready" target="ready"/>
> <transition event="tester.PnotReady" target="not_ready"/>
> <state id="ready">
> <transition event="tester.notReady"
> target="not_ready"/>
> </state>
> <state id="not_ready">
> <transition event="tester.ready" target="ready"/>
> </state>
> <history id="resume_agent_status" type="deep">
> <transition target="ready"/>
> </history>
> </state>
> <state id="channel_status">
> <initial>
> <transition target="resume_channel_status"/>
> </initial>
> <transition event="tester.Pdial" target="on_call" />
> <transition event="tester.Phangup" target="off_call" />
> <state id="off_call">
> <transition event="tester.dial" target="on_call" />
>
> </state>
> <state id="on_call">
> <transition event="tester.hangup" target="off_call"
> />
> </state>
> <history id="resume_channel_status" type="deep">
> <transition target="off_call"/>
> </history>
> </state>
> </parallel>
>
> However, the result appears to be similar but with some additional strange
> behavior if I transition to a state I'm already in - I suspect the
> transitions and histories are conflicting with each other. (?)
>
> Still wondering if there's any way to use "catch-all" transitions in parent
> states when the parent states are parallel.
>
<snap/>
Add an intermediate <state> that prevents the exit from the orthogonal region.
So, instead of this pattern:
<parallel id="par">
<state id="region1">
<initial>
<transition target="foo"/>
</initial>
<transition event="trigger" target="bar"/>
<!-- foo, bar and other content -->
</state>
<!-- other regions -->
</parallel>
use the following pattern instead:
<parallel id="par">
<state id="region1">
<initial>
<transition target="intermediate"/>
</initial>
<!-- the following contains content of region1 before -->
<state id="intermediate">
<initial>
<transition target="foo"/>
</initial>
<transition event="trigger" target="bar"/>
<!-- foo, bar and other content -->
</state>
</state>
<!-- other regions -->
</parallel>
-Rahul
> - Bill
>
>
> On Jan 8, 2010, at 10:25 AM, Bill Herring wrote:
>
>> I'm working with a state model with two parallel states that each have
>> substates:
>>
>> <parallel id="channel">
>> <state id="agent_status" initial="ready">
>> <transition event="parent.goReady" target="ready"/>
>> <transition event="parent.goNotReady"
>> target="not_ready"/>
>> <state id="ready">
>> <transition event="goNotReady" target="not_ready"/>
>> </state>
>> <state id="not_ready">
>> <transition event="goReady" target="ready"/>
>> </state>
>> </state>
>>
>> <state id="channel_status" initial="off_call">
>> <transition event="parent.dial" target="on_call" />
>> <transition event="parent.hangup" target="off_call" />
>> <state id="off_call">
>> <transition event="dial" target="on_call" />
>> </state>
>> <state id="on_call">
>> <transition event="hangup" target="off_call" />
>> </state>
>> </state>
>> </parallel>
>>
>> When I trigger transitions with the "leaf events" (goNotReady, goReady,
>> dial, and hangup) everything works as I would expect - the two parallel
>> states transition between substates independently. However, if I trigger
>> transitions using the "parent events" (parent.X), the transition occurs in
>> the one parallel substate and the other parallel substate apparently
>> "resets" to its initial state. As a concrete example, if I trigger
>> "parent.goNotReady" followed by "parent.dial" I end up in "on_call" and
>> "ready" (vs. "on_call" and "not_ready", which I would be in if I has used
>> "goNotReady" and "dial" instead).
>>
>> Is this a feature or a bug? Is there a way to get the same behavior in
>> both cases? I realize that in this trivial example there's no real
>> advantage to putting the transitions in parent states, but I have a much
>> more complex state model where I want to put "catch all" transitions in
>> parent states and this behavior is stopping me from doing that.
>>
>> Thanks,
>> Bill
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Parallel parent states resetting to initial substates?
Posted by Bill Herring <bh...@openmethods.com>.
OK, I found that it is indeed a feature (Section 3.3.3 of the SCXML
spec), but I still need the behavior I describe in my original email.
In an attempt to fix the problem, I added history states to the two
parallel parent states, like this:
<parallel id="open_channel">
<state id="agent_status">
<initial>
<transition target="resume_agent_status"/>
</initial>
<transition event="tester.Pready" target="ready"/>
<transition event="tester.PnotReady" target="not_ready"/>
<state id="ready">
<transition event="tester.notReady" target="not_ready"/>
</state>
<state id="not_ready">
<transition event="tester.ready" target="ready"/>
</state>
<history id="resume_agent_status" type="deep">
<transition target="ready"/>
</history>
</state>
<state id="channel_status">
<initial>
<transition target="resume_channel_status"/>
</initial>
<transition event="tester.Pdial" target="on_call" />
<transition event="tester.Phangup" target="off_call" />
<state id="off_call">
<transition event="tester.dial" target="on_call" />
</state>
<state id="on_call">
<transition event="tester.hangup" target="off_call" />
</state>
<history id="resume_channel_status" type="deep">
<transition target="off_call"/>
</history>
</state>
</parallel>
However, the result appears to be similar but with some additional
strange behavior if I transition to a state I'm already in - I suspect
the transitions and histories are conflicting with each other. (?)
Still wondering if there's any way to use "catch-all" transitions in
parent states when the parent states are parallel.
- Bill
On Jan 8, 2010, at 10:25 AM, Bill Herring wrote:
> I'm working with a state model with two parallel states that each
> have substates:
>
> <parallel id="channel">
> <state id="agent_status" initial="ready">
> <transition event="parent.goReady" target="ready"/>
> <transition event="parent.goNotReady" target="not_ready"/>
> <state id="ready">
> <transition event="goNotReady" target="not_ready"/>
> </state>
> <state id="not_ready">
> <transition event="goReady" target="ready"/>
> </state>
> </state>
>
> <state id="channel_status" initial="off_call">
> <transition event="parent.dial" target="on_call" />
> <transition event="parent.hangup" target="off_call" />
> <state id="off_call">
> <transition event="dial" target="on_call" />
> </state>
> <state id="on_call">
> <transition event="hangup" target="off_call" />
> </state>
> </state>
> </parallel>
>
> When I trigger transitions with the "leaf events" (goNotReady,
> goReady, dial, and hangup) everything works as I would expect - the
> two parallel states transition between substates independently.
> However, if I trigger transitions using the "parent
> events" (parent.X), the transition occurs in the one parallel
> substate and the other parallel substate apparently "resets" to its
> initial state. As a concrete example, if I trigger
> "parent.goNotReady" followed by "parent.dial" I end up in "on_call"
> and "ready" (vs. "on_call" and "not_ready", which I would be in if I
> has used "goNotReady" and "dial" instead).
>
> Is this a feature or a bug? Is there a way to get the same behavior
> in both cases? I realize that in this trivial example there's no
> real advantage to putting the transitions in parent states, but I
> have a much more complex state model where I want to put "catch all"
> transitions in parent states and this behavior is stopping me from
> doing that.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
[SCXML] Parallel parent states resetting to initial substates?
Posted by Bill Herring <bh...@openmethods.com>.
I'm working with a state model with two parallel states that each have
substates:
<parallel id="channel">
<state id="agent_status" initial="ready">
<transition event="parent.goReady" target="ready"/>
<transition event="parent.goNotReady" target="not_ready"/>
<state id="ready">
<transition event="goNotReady" target="not_ready"/>
</state>
<state id="not_ready">
<transition event="goReady" target="ready"/>
</state>
</state>
<state id="channel_status" initial="off_call">
<transition event="parent.dial" target="on_call" />
<transition event="parent.hangup" target="off_call" />
<state id="off_call">
<transition event="dial" target="on_call" />
</state>
<state id="on_call">
<transition event="hangup" target="off_call" />
</state>
</state>
</parallel>
When I trigger transitions with the "leaf events" (goNotReady,
goReady, dial, and hangup) everything works as I would expect - the
two parallel states transition between substates independently.
However, if I trigger transitions using the "parent
events" (parent.X), the transition occurs in the one parallel substate
and the other parallel substate apparently "resets" to its initial
state. As a concrete example, if I trigger "parent.goNotReady"
followed by "parent.dial" I end up in "on_call" and "ready" (vs.
"on_call" and "not_ready", which I would be in if I has used
"goNotReady" and "dial" instead).
Is this a feature or a bug? Is there a way to get the same behavior
in both cases? I realize that in this trivial example there's no real
advantage to putting the transitions in parent states, but I have a
much more complex state model where I want to put "catch all"
transitions in parent states and this behavior is stopping me from
doing that.
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] History in parallel?
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, Jan 13, 2010 at 6:24 PM, Bill Herring <bh...@openmethods.com> wrote:
> I didn't think of that, and it's more elegant than the workaround I used,
> which was to put history tags in the talk_status, call_status, etc. inside
> the parallel state and target those histories instead of a single one.
> Thanks for the tip! I'll make sure I prefix future subject lines with
> SCXML too.
>
> Also, have another unrelated question - please let me know if you'd rather
> me post it to the list under a new subject, and I'll do so.
>
<snip/>
Yup, updated email subjects are useful (for the archives etc.). If
this discussion continues, please use an appropriate subject for your
next post, thanks!
> In my ignorance of CommonsSCXML (I picked it up a few weeks ago), I'm trying
> to programatically inject some bits of data into the datamodel for a state
> before I fire an event that will target that state. Then when the
> transition fires and the target state is reached, a <send> that makes use of
> the datamodel (ala the namelist attribute) fires onentry. The goal is to
> communicate data from one "client" of the state machine to another.
>
> If this seems overly complicated, perhaps it is... But assuming there's not
> a better way, my current problem is that I can modify the datamodel of the
> target easily enough, via getDataModel() and setDateModel(). This works
> fine the first time, but fails to "send" any new data after that because the
> target state's context gets created once and then is not updated when I
> change the datamodel - the two are out of synch.
>
<snap/>
Yup, thats the template vs. instance distinction -- changes to the
model won't be picked up once a state machine executor instance is set
in motion. Indeed, the data model for an SCXML defined state machine
is supposed to be fully populated and available at load time. There
are usecases for injecting parts of the datamodel at state machine run
time, but such client usage needs to be responsible (Commons SCXML
provides a limited means to this by allowing access to the root
context as you note). Ideally, one would not touch the datamodel while
events are being processed or transitions are being filtered for
example. Any additional information may come in as event payloads and
be utilized / copied to the appropriate datamodel using executable
actions such as assign (this ensures that such behavior is modeled as
part of the state machine, rather than procedural injection that is
otherwise invisible to the reader of the SCXML document).
> So I need to be able to synch the two - there are public methods to get the
> root context, but how do you get the context for a specific state?
<snip/>
Following the mantra of modeling the state machine entirely as SCXML,
rather than procedurally injecting such data, one can use event
payloads and custom actions to perform this. So, lets say the data to
be added comes in as the payload of event with name "foo.bar", then on
transition one could populate the specific state context like so:
<scxml:transition event="foo.bar" ...>
<my:save stateid="baz" .../> <!-- payload has data for baz's context -->
</scxml:transition>
such that <my:save> is a fictitious custom action that is a fancy
version of assign for your usecase. Custom actions have access to all
of the state machine instance (via the SCInstance parameter of the
Action#execute method). Ofcourse, may need to adjust per taste -- but
do investigate whether this is a suitable pattern for your usecase.
> I guess
> I could just use the root context to do everything, but that seems clumsy,
> and I'm interested in how I can manipulate other contexts anyway (preferably
> without modifying the CommonsSCXML interfaces).
>
<snap/>
In addition to my comments above, note that there have been
discussions in the Working Group about removing data model scoping
altogether. IOW, there may be a flat scope for SCXML documents i.e.
only one context for the entire SCXML document going forward.
Ofcourse, we will have to wait for the next Working Draft to see if
this change goes through. And in that case, using the root context for
everything will be a necessity rather than a choice (though Commons
SCXML is designed so we can continue to support all kinds of scoping
patterns users need).
> There are clearly other ways to structure the passing of such data, but I am
> assuming that the code that fires the transitioning event and the code that
> handles the send event have no way to communicate other than via the state
> machine. Also, I don't want to depend on the send event being handled
> immediately after the firing of the transition event, even though that may
> be the case in my current implementation (i.e. another transition might
> happen and trigger another send before the current one is processed).
<snip/>
Right. The solution above takes care of that (<my:save> happens in the
said <transition> and the current event payload will persist inspite
of other <send>s etc.).
> And,
> finally, though I can see ways to not use it, I believe <send> best reflects
> my intent - to send a message to an object/thread/program that is external
> to the state machine.
<snap/>
Seems reasonable with the details so far.
-Rahul
> Of course, I could be wrong... :)
>
> Thanks again for your help,
> Bill
>
>
> On Jan 13, 2010, at 3:40 PM, Rahul Akolkar wrote:
>
>> Please prefix the email subject with the Commons component name when
>> posting, as I've done here (since this is a shared mailing list).
>> Response below ...
>>
>> On Thu, Jan 7, 2010 at 5:51 PM, Bill Herring <bh...@openmethods.com>
>> wrote:
>>>
>>> My reading of the latest W3C working draft is that SCXML supports history
>>> pseudo-states in parallel ones. When I run my app with the SCXML model
>>> below, I get:
>>> WARNING: Ignoring element <history> in namespace
>>> "http://www.w3.org/2005/07/scxml"
>>> and then it cannot find the two resume_ targets.
>>>
>>> Does Commons SCXML support history elements as parallel children? Am I
>>> doing something wrong here?
>>>
>> <snip/>
>>
>> The current release (v0.9) does not support history in parallel.
>>
>> Work has been done in a development branch on a version of the parser
>> that does support history as used below, but its yet incomplete and
>> unreleased.
>>
>> While using v0.9, I'd suggest using a state wrapper element around the
>> parallel to hold the deep history.
>>
>> -Rahul
>>
>>
>>> <?xml version="1.0"?>
>>>
>>> <scxml xmlns="http://www.w3.org/2005/07/scxml"
>>> version="1.0" initial="off_call">
>>> <state id="off_call">
>>> <transition event="dial" target="call_active"/>
>>> </state>
>>> <parallel id="call_active">
>>> <state id="talk_status" initial="talking">
>>> <state id="talking">
>>> <transition event="hold" target="held" />
>>> </state>
>>> <state id="held">
>>> <transition event="retrieve"
>>> target="talking" />
>>> </state>
>>> </state> <!-- END talk_status -->
>>> <state id="call_status" initial="on_call">
>>> <state id="on_call">
>>> <transition event="hangup"
>>> target="off_call"/>
>>> <transition event="consult"
>>> target="consult_active"/>
>>> </state>
>>> <state id="on_call_consult">
>>> <transition event="hangup"
>>> target="off_call"/>
>>> <transition event="alternate"
>>> target="resume_consult"/>
>>> </state>
>>> </state> <!-- END call_status -->
>>> <history id="resume_call" type="deep"/>
>>>
>>> </parallel> <!-- END call_active -->
>>> <parallel id="consult_active">
>>> <state id="consult_talk_status" initial="consult_talking">
>>> <state id="consult_talking">
>>> <transition event="hold"
>>> target="consult_held" />
>>> </state>
>>> <state id="consult_held">
>>> <transition event="retrieve"
>>> target="consult_talking" />
>>> </state>
>>> </state> <!-- END consult_talk_status -->
>>> <state id="consult_status" initial="on_consult">
>>> <state id="on_consult">
>>> <transition event="hangup"
>>> target="resume_call"/>
>>> <transition event="alternate"
>>> target="resume_call"/>
>>> </state>
>>> </state> <!-- END consult_status -->
>>> <history id="resume_consult" type="deep"/>
>>>
>>> </parallel> <!-- END consult_active -->
>>> </scxml>
>>>
>>>
>>> Thanks,
>>> Bill
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
> Bill Herring
> OpenMethods
> 4741 Central Street | Suite 285 | Kansas City, MO | 64112-1533
> o| +1.816.283.VXML (8965) x105
> bherring@openmethods.com | www.openmethods.com
> P This email is composed of 100% recycled electrons. Please print only when
> necessary.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] History in parallel?
Posted by Bill Herring <bh...@openmethods.com>.
I didn't think of that, and it's more elegant than the workaround I
used, which was to put history tags in the talk_status, call_status,
etc. inside the parallel state and target those histories instead of a
single one. Thanks for the tip! I'll make sure I prefix future
subject lines with SCXML too.
Also, have another unrelated question - please let me know if you'd
rather me post it to the list under a new subject, and I'll do so.
In my ignorance of CommonsSCXML (I picked it up a few weeks ago), I'm
trying to programatically inject some bits of data into the datamodel
for a state before I fire an event that will target that state. Then
when the transition fires and the target state is reached, a <send>
that makes use of the datamodel (ala the namelist attribute) fires
onentry. The goal is to communicate data from one "client" of the
state machine to another.
If this seems overly complicated, perhaps it is... But assuming
there's not a better way, my current problem is that I can modify the
datamodel of the target easily enough, via getDataModel() and
setDateModel(). This works fine the first time, but fails to "send"
any new data after that because the target state's context gets
created once and then is not updated when I change the datamodel - the
two are out of synch.
So I need to be able to synch the two - there are public methods to
get the root context, but how do you get the context for a specific
state? I guess I could just use the root context to do everything,
but that seems clumsy, and I'm interested in how I can manipulate
other contexts anyway (preferably without modifying the CommonsSCXML
interfaces).
There are clearly other ways to structure the passing of such data,
but I am assuming that the code that fires the transitioning event and
the code that handles the send event have no way to communicate other
than via the state machine. Also, I don't want to depend on the send
event being handled immediately after the firing of the transition
event, even though that may be the case in my current implementation
(i.e. another transition might happen and trigger another send before
the current one is processed). And, finally, though I can see ways to
not use it, I believe <send> best reflects my intent - to send a
message to an object/thread/program that is external to the state
machine. Of course, I could be wrong... :)
Thanks again for your help,
Bill
On Jan 13, 2010, at 3:40 PM, Rahul Akolkar wrote:
> Please prefix the email subject with the Commons component name when
> posting, as I've done here (since this is a shared mailing list).
> Response below ...
>
> On Thu, Jan 7, 2010 at 5:51 PM, Bill Herring
> <bh...@openmethods.com> wrote:
>> My reading of the latest W3C working draft is that SCXML supports
>> history
>> pseudo-states in parallel ones. When I run my app with the SCXML
>> model
>> below, I get:
>> WARNING: Ignoring element <history> in namespace
>> "http://www.w3.org/2005/07/scxml"
>> and then it cannot find the two resume_ targets.
>>
>> Does Commons SCXML support history elements as parallel children?
>> Am I
>> doing something wrong here?
>>
> <snip/>
>
> The current release (v0.9) does not support history in parallel.
>
> Work has been done in a development branch on a version of the parser
> that does support history as used below, but its yet incomplete and
> unreleased.
>
> While using v0.9, I'd suggest using a state wrapper element around the
> parallel to hold the deep history.
>
> -Rahul
>
>
>> <?xml version="1.0"?>
>>
>> <scxml xmlns="http://www.w3.org/2005/07/scxml"
>> version="1.0" initial="off_call">
>> <state id="off_call">
>> <transition event="dial" target="call_active"/>
>> </state>
>> <parallel id="call_active">
>> <state id="talk_status" initial="talking">
>> <state id="talking">
>> <transition event="hold"
>> target="held" />
>> </state>
>> <state id="held">
>> <transition event="retrieve"
>> target="talking" />
>> </state>
>> </state> <!-- END talk_status -->
>> <state id="call_status" initial="on_call">
>> <state id="on_call">
>> <transition event="hangup"
>> target="off_call"/>
>> <transition event="consult"
>> target="consult_active"/>
>> </state>
>> <state id="on_call_consult">
>> <transition event="hangup"
>> target="off_call"/>
>> <transition event="alternate"
>> target="resume_consult"/>
>> </state>
>> </state> <!-- END call_status -->
>> <history id="resume_call" type="deep"/>
>>
>> </parallel> <!-- END call_active -->
>> <parallel id="consult_active">
>> <state id="consult_talk_status"
>> initial="consult_talking">
>> <state id="consult_talking">
>> <transition event="hold"
>> target="consult_held" />
>> </state>
>> <state id="consult_held">
>> <transition event="retrieve"
>> target="consult_talking" />
>> </state>
>> </state> <!-- END consult_talk_status -->
>> <state id="consult_status" initial="on_consult">
>> <state id="on_consult">
>> <transition event="hangup"
>> target="resume_call"/>
>> <transition event="alternate"
>> target="resume_call"/>
>> </state>
>> </state> <!-- END consult_status -->
>> <history id="resume_consult" type="deep"/>
>>
>> </parallel> <!-- END consult_active -->
>> </scxml>
>>
>>
>> Thanks,
>> Bill
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
Bill Herring
OpenMethods
4741 Central Street | Suite 285 | Kansas City, MO | 64112-1533
o| +1.816.283.VXML (8965) x105
bherring@openmethods.com | www.openmethods.com
P This email is composed of 100% recycled electrons. Please print only
when necessary.
Re: [SCXML] History in parallel?
Posted by Rahul Akolkar <ra...@gmail.com>.
Please prefix the email subject with the Commons component name when
posting, as I've done here (since this is a shared mailing list).
Response below ...
On Thu, Jan 7, 2010 at 5:51 PM, Bill Herring <bh...@openmethods.com> wrote:
> My reading of the latest W3C working draft is that SCXML supports history
> pseudo-states in parallel ones. When I run my app with the SCXML model
> below, I get:
> WARNING: Ignoring element <history> in namespace
> "http://www.w3.org/2005/07/scxml"
> and then it cannot find the two resume_ targets.
>
> Does Commons SCXML support history elements as parallel children? Am I
> doing something wrong here?
>
<snip/>
The current release (v0.9) does not support history in parallel.
Work has been done in a development branch on a version of the parser
that does support history as used below, but its yet incomplete and
unreleased.
While using v0.9, I'd suggest using a state wrapper element around the
parallel to hold the deep history.
-Rahul
> <?xml version="1.0"?>
>
> <scxml xmlns="http://www.w3.org/2005/07/scxml"
> version="1.0" initial="off_call">
> <state id="off_call">
> <transition event="dial" target="call_active"/>
> </state>
> <parallel id="call_active">
> <state id="talk_status" initial="talking">
> <state id="talking">
> <transition event="hold" target="held" />
> </state>
> <state id="held">
> <transition event="retrieve"
> target="talking" />
> </state>
> </state> <!-- END talk_status -->
> <state id="call_status" initial="on_call">
> <state id="on_call">
> <transition event="hangup"
> target="off_call"/>
> <transition event="consult"
> target="consult_active"/>
> </state>
> <state id="on_call_consult">
> <transition event="hangup"
> target="off_call"/>
> <transition event="alternate"
> target="resume_consult"/>
> </state>
> </state> <!-- END call_status -->
> <history id="resume_call" type="deep"/>
>
> </parallel> <!-- END call_active -->
> <parallel id="consult_active">
> <state id="consult_talk_status" initial="consult_talking">
> <state id="consult_talking">
> <transition event="hold"
> target="consult_held" />
> </state>
> <state id="consult_held">
> <transition event="retrieve"
> target="consult_talking" />
> </state>
> </state> <!-- END consult_talk_status -->
> <state id="consult_status" initial="on_consult">
> <state id="on_consult">
> <transition event="hangup"
> target="resume_call"/>
> <transition event="alternate"
> target="resume_call"/>
> </state>
> </state> <!-- END consult_status -->
> <history id="resume_consult" type="deep"/>
>
> </parallel> <!-- END consult_active -->
> </scxml>
>
>
> Thanks,
> Bill
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org