SCXML: discrepancy in the standard?

Hi,

version 20080516 was the first SCXML-specification, that allowed the 
<scxml> node to have an <initial> element. Later, in version 20100513 
the <initial> element was removed from the list of children, which is 
still the case in the current specification.

What was the reason for this decision? Are there reasons, why the 
<scxml> node should not have an <initial> element?

As I understand the subject, not allowing <initial> as a child of a 
<scxml> node, has two consequences:

1)
It is no longer possible to execute an action on the initialization of 
the state machine. The initial attribute of the <scxml> node is not a 
substitute, because such transitions can not contain any executable 
content.

I can not see any apparent reason, why it should not be possible to 
define executable content associated with the initialization of the 
state machine. In my point of view, this is common practice and used 
frequently.

2)
Appendix A of the current specification "presents a normative algorithm 
for the interpretation of SCXML documents". It requests: 
"Implementations are free to implement SCXML interpreters in any way 
they choose, but they must behave as if they were using the algorithm 
defined here."

The algorithm states: "In order to interpret an SCXML document, first 
convert initial attributes to <initial> container children with 
transitions to the state specified by the attribute (such transitions 
will not contain any executable content). Then (optionally) validate the 
resulting SCXML, and throw an exception if validation fails."

This algorithm is mandatory since version 20080516.

So, as I understand the algorithm, the example in Main.scxml

[...]
<scxml xmlns="http://www.w3.org/2005/07/scxml"
        version="1.0"
        initial="Main"
        datamodel="ecmascript">
   <state id="Main">
   [...]

is first converted to

[...]
<scxml xmlns="http://www.w3.org/2005/07/scxml"
        version="1.0"
        datamodel="ecmascript">
   <initial>
      <transition target="Main"/>
   </initial>
   <state id="Main">
   [...]

and then checked, if it is a valid SCXML-document.

Because <initial> elements are not allowed as children of a <scxml> 
node, the validation must fail in any case. According to the 
specification and according to the schema, the second listing is not 
valid SCXML-code. In other words: The specification requests 
transformations that lead to invalid results.


Conclusion and Question:
I guess, that the <initial> element in the list of children of the 
<scxml> node simply got lost from the 20091029 version of the 
specification to the later ones and should still be there, because it is 
necessary.

Is that right?

If not, why not? What is wrong with my considerations? What did I 
misunderstand?
If yes, are there attempts to reintroduce the <initial> element in the 
list of children of the <scxml> node in the specification and the 
schema? When is the next release of the standard planned?


I welcome your feedback very much. Thanks in advance.

Kind regards,
Volker Spinke

Received on Tuesday, 3 January 2012 00:04:19 UTC