On Fri, Feb 17, 2012 at 10:50 AM, Ingo Lütkebohle <iluetkeb@gmail.com>wrote:

> 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!


I think they're very similar, if not equivalent. I mean to emphasize that
some of those more advanced features are actually very useful for
task-level coordination, and we shouldn't limit ourselves to the subset of
that specification that only describes the state-machine logic.