On Fri, Feb 17, 2012 at 2:36 PM, Jonathan Bohren
<
jonathan.bohren@gmail.com> wrote:
>> I agree, and we deliberately only use a subset of SCXML's
>> functionality, with other features being rejected at design time.
>> However, everything that I want to express in a state-machine
>> language, I can express in it. That's a very good start, in my
>> opinion, and something that is otherwise lacking.
> Well, I think going to a pure state-machine / state-chart specification
> would be a step back. The reason why we created SMACH in the first place was
> because in robotics applications and experiments, we often want more than
> what just an FSM-equivalent representation would allow us to specify.
> Remember, the SMACH semantics are more like a switched hybrid system than a
> pure FSM, since the true "state" at any given time is not only the task
> state but also the state of the data flowing between the task states.
Do you mean the container-state functionality?
SCXML has something which, as far as I can tell, is equivalent: The
data-model. It allows you to define attributes within the state-chart
specification, which can be filled from events and/or return values of
both local and remote invocations, and used for conditions or calls.
See
http://www.w3.org/TR/scxml/#data-module
I would consider that equivalent to the container state functionality,
but then you're the expert there, so if you there are significant
differences, please let me know!
cheers,
--
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/
PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B