RE: SCXML: discrepancy in the standard?

Volker,
  Upon reflection we were struck by the stunningly obvious insight that
all we have to do is to switch the order of the validation and the
conversion of the 'initial' attributes in the algorithm.  We've also
added an explanation that the only reason for the conversion is to
simplify the statement of the algorithm  (I wouldn't expect most
implementations to do the conversion.)  

As for turning <scxml> into a 'pure' wrapper element, we think that the
current syntax makes it simpler to write concise state machines.
Furthermore it seems reasonable for a wrapper element to hold an
indication of the entry point.  

We hope to publish a new draft soon which will contain this modification
(and fix a number of other bugs in the algorithm.) Thank you for your
comments.  
Best,
Jim Barnett

-----Original Message-----
From: vs@spinke.de [mailto:vs@spinke.de] 
Sent: Wednesday, January 04, 2012 11:39 AM
To: www-voice@w3.org
Subject: Re: SCXML: discrepancy in the standard?

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.
> 					
>



					
-------------------------------------------------------------------------------------------------------------------
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 Monday, 16 January 2012 22:13:57 UTC