RE: SCXML: discrepancy in the standard?

Jacob,
  I don't think that the current treatment of <scxml> adds much complexity to the spec.  As far as I am aware, there is only one additional statement in the spec that is necessary due to the fact that <scxml> can have multiple state children.  It's contained in Section 3.11 and stipulates that only one of <scxml>'s children can be active.

There is one other place where the <scxml> node gets special treatment, and that's in "FindLeastCommonAncestor" in the algorithm.  Here we have to handle the fact that the common ancestor of the source and target states of a transition may be <scxml).  However, even if <scxml> were restricted to having only a single child, any transition that exited and re-entered that <state> would still have <scxml> as its least common ancestor, so we wouldn't be able to insist that the least common ancestor always be a state.

- Jim 
 

-----Original Message-----
From: Jacob Beard [mailto:jbeard4@cs.mcgill.ca] 
Sent: Thursday, January 19, 2012 12:28 PM
To: www-voice
Subject: Re: SCXML: discrepancy in the standard?

IMHO, as both a user and implementer of the SCXML spec, I write SCXML documents by hand quite a lot, and I appreciate the extra conciseness.
I agree that making the root scxml element a kind of special state adds complexity to the specification, and this approach is inconsistent with other state machine specifications (for example, UML
2.0 State Machines have an explicit StateMachine class which is associated with 0 or 1 State children:
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF), however I haven't found that the current approach used by SCXML has increased the complexity of developing a functional interpreter, or of developing tools which utilize static analysis for verification and optimization.

Cheers,

Jake

On Thu, Jan 19, 2012 at 11:53 AM,  <vs@spinke.de> wrote:
> Dear Jim,
>
> editorial changes only hide the problems in the standard, but do not 
> solve them. Being an executive, you are much more interested in 
> company politics than in getting the standard right. As a linguist, 
> you are also highly qualified to judge other peoples implementations. I clearly understand both.
>
> At first, I thought I would talk to experts in the field, but that is 
> obviously not the case, as it turns out now. Also the other members of 
> the working group are mainly managers too. Taking this into account, 
> it is no wonder any more, that saving negligible fifteen characters in 
> the scxml-file (which are necessary most of the time anyway) is a much 
> more important goal for the working group, than getting the 
> inconsistencies and self-contradictions out of the standard. Defining 
> the language in a general form with a clear, consistent and regular 
> structure would help authors as well as implementers to write concise 
> state machines and efficient implementations, but as managers this is 
> naturally not your and your peers business.
>
> Upon reflection of the actual situation, I was struck by the 
> stunningly obvious insight, that the working group is unwilling to 
> make the SCXML standard useful to anybody, except for its own members. 
> All, I have to do now, is to define my own language (fixing all the 
> serious bugs in scxml you leave intentionally). It is a pity, but the only way to get things done.
> Thanks a lot, for making this consequence very clear.
>
> I hope that other users of SCXML are also struck by the stunningly 
> obvious insight into the self-esteem of the working group, which helps 
> them to understand the reasons for the painfully elusive definitions 
> and head-aching structure of the standard.
>
> Thanks to all members of the working group for the lesson.
>
> Yours,
> Volker Spinke
>
>
>
> On 16.01.2012 23:13, Jim Barnett wrote:
>>
>> 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
>>
>


					
-------------------------------------------------------------------------------------------------------------------
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 Thursday, 19 January 2012 17:59:56 UTC