W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2012

Re: SCXML: discrepancy in the standard?

From: <vs@spinke.de>
Date: Wed, 04 Jan 2012 17:38:46 +0100
Message-ID: <4F048096.1000100@spinke.de>
To: www-voice@w3.org
Hi Jim,

thanks for your kind answer.

I thought a bit more about the subject and came to the conclusion that 
the reason for the inconsistency is the role of the <scxml> node. It 
seems that it changed over the evolution of the standard and is still 
not as clearly defined as it should be.

The current version of the standard says about <scxml>: "The top-level 
wrapper element, which carries version information. The actual state 
machine consists of its children." In contrast to this, earlier versions 
say: "The top-level root state, which carries version information etc." 
Before this, is was explained as: "The top-level root element, which 
carries version information etc."

There are two possible point of views, which have different consequences:


1) The <scxml> node is the top-level state of the state machine.

In this case, it must allow ALL children, that are allowed for <state> / 
<parallel> / <final> too. This is obvious, because it is a state. The 
only difference is, that it has no ancestors in contrast to the other 
states. As a result, if this is the meaning of the <scxml> tag, the list 
of children would have to be expanded.


2)The <scxml> node is only wrapper element, which carries version 
information and some processing directives. The actual state machine 
consists of its child (not of its children!).

In this case, the <scxml> node must not have an initial attribute and it 
must have ONE and only one child, which can be one out of the three 
possibilities <state> / <parallel> / <final>. Other children are not 
allowed.


At first, I preferred the first point of view, because I viewed the 
top-level element as the root state. But the second point of view is 
actually clearer. It separates the version and processing information 
from the state logic. Because it is a wrapper only, it is possible to 
reuse the state logic in a more complex application without any changes. 
If the <scxml> node is a kind of a state, it introduces a forth type of 
state, that can not be reused in an other context, if the <scxml> node 
can occur only once in a SCXML-Document. So, I am in favor of the second 
point of view now, because it separates the concerns, has no apparent 
disadvantages over the other but introduces advantages, not possible 
with the first point of view. It also dissolves the ambiguities I raised 
with my first email.


As a result, I suggest the following changes to the standard for discussion:
a) The role of the <scxml> node element should be described clearer.
Something like: "The top-level wrapper element, which carries version 
and processing information only. The actual state machine consists of 
its child. Only one <scxml> node in a SCXML-document is allowed."
b) The initial-attribute must be removed in the table of <scxml>.
c) The number of children of <scxml> is one and must be one out of three 
possibilities which are mutually exclusive: <state>, <parallel> or 
<final>. As a result, this state (defined as the only child element of 
the <scxml> node) is the top-level root state of the state machine, 
because it does not have any ancestors. It is automatically also the 
initial state, because of the rule "If neither the <initial> child or 
the 'initial' element is specified, the default initial state is the 
first child state in document order." As there is no initial-attribute, 
no <initial> child element and no sibling states, the algorithm in 
Appendix A is correct. Expanding initial-attributes to <initial> 
children is correct, because it now happens on state elements only, 
where it is allowed and save.
d) The examples must be revised. There are more mistakes than the 
initial-attribute of the <scxml> tag. As this is not the topic of this 
thread, I do not go into details here.

With these changes to the language, algorithm and language are 
consistent again.


I am looking forward to hearing from you.

Kind regards
Volker Spinke


On 03.01.2012 17:19, Jim Barnett wrote:
> 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 Wednesday, 4 January 2012 16:48:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 January 2012 16:48:49 GMT