RE: SCXML specification

Michael,

 Concerning your questions:

1)       We have discussed this issue within the group several times and each time the conclusion has been that in an XML language it is useful to have a distinct root element that is not equivalent to its descendant elements.  We haven't found a compelling argument in either direction, though, and will probably revisit the issue again.  If you put a single top-level state as the unique child of <scxml>, you can get the same behavior as if <scxm> was itself a state.  

2)       You're right and the phrasing is inaccurate.  The <onentry> element will be executed.  The <initial> element allows for additional executable content which will be executed only on default entry (while the <onentry> is executed no matter how the state is entered.)  We'll change the wording in the next draft.

3)       That's a very interesting question.  We haven't considered whether the history state may be the value of the initial attribute.  In general, we have always assumed that you do need to specify the history state directly as the target of the transition.  For more dynamic behavior, you can jump back to a previous state without specifying the history state ID directly in the transition by using the 'anchor' attribute. 

4)       You should be able to define a profile that will give you any conditional language you want.  For example, the XPath profile specifies that conditional expressions are XPath2 expressions, while the ECMA profile specifies them as ECMAScript expressions.  You can define a profile that allows your functors as conditional expressions.  The only restrictions are: 1) they must return a Boolean value 2) they must not have side-effects.  

 

- Jim

 

________________________________

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Michael Traut
Sent: Thursday, September 18, 2008 10:58 AM
To: www-voice@w3.org
Subject: SCXML specification

 


Dear sirs, 

currently i am about to move my statemachine engine towards the SCXML standard. There are some issues and questions i found and i hope you can help me to a better understanding or improvement of the upcoming standard. 

1) 3.1 - scxml 

why is the definition "half hearted" recursive? the root may not contain 
        - "onentry" this would be a natural place to put initalization action, as opposed to the "script" extension 
        - "onexit" the same as above - just for symmetry 
        - "transition" transitions that are inherited by the states within the "compound state" scxml 
        - "history" - very important!! currently i see no way to express the possibiltiy to enter a whole machine at a defined state. Why? 

in my opinion the root as currently defined is a (compound) state itself and should allow for that. 

2) 3.5 - initial 

the description of the semantics is somehow misleading "If the initial attribute is specified, the specified state willbe entered, but no executable content will be executed". I assume, the "onentry" action is executed anyway. 

3) 3.9 - history 

maybe this is obvious, but it took me some time to figure out from the pseudo semantics (maybe erroneous): If i enter a compound state there should be a way to enter a historical state without specifing the history state directly. This decision may be up to the state node himself. This can be done (am i right?) by specifying the history state as the initial state of the compound state? 

4) 3.3 - transition 

while we have a very easy way of extending the action / executables, this is much more problematic with conditions. My current implementation works with generic "Functor" objects that can be plugged anywhere the spec allows actions. This is fine as they can be expressed as elements of the form <perform type="??" source="??"/>. These functors allow an "implementation language" on a per instance base. This syntax is not suitable for conditions, as these are restricted to string expressions. It would be a great improvement if i were able to express conditions as functors. this would mean that i need an element based definition. 

I am looking forward for your reply, many thanks. 

kind regards,
Michael Traut

---------------------------------------------------------------------
Fon:  +49 721 38479-12
Fax:  +49 721 38479-60
Mobil: +49 172 7232017
Mail: mtraut@intarsys.de
---------------------------------------------------------------------

intarsys consulting GmbH
Bahnhofplatz 8, D-76137 Karlsruhe
Geschäftsführer: 
Dr. Bernd Wild, Karl Kagermeier, Michael Traut
Sitz der Gesellschaft: Karlsruhe
Registergericht: Amtsgericht Mannheim HRB 107535
Web: http://www.intarsys.de