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