RE: SCXML: discrepancy in the standard?

Volker,
  You have a good point.  It certainly seems that the algorithm is
inconsistent with the language in the spec.  We will discuss the issue
in the working group and get back to you.

- Jim Barnett

-----Original Message-----
From: vs@spinke.de [mailto:vs@spinke.de] 
Sent: Monday, January 02, 2012 4:28 PM
To: www-voice@w3.org
Subject: 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



					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Received on Tuesday, 3 January 2012 16:20:47 UTC