On Fri, Feb 17, 2012 at 2:36 PM, Jonathan Bohren 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