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.