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

Re: SCXML: discrepancy in the standard?

From: Jacob Beard <jbeard4@cs.mcgill.ca>
Date: Thu, 19 Jan 2012 12:28:29 -0500
Message-ID: <CADywnFhPdtkSJcYPDHhpwmMhbWbW2WnZbbTYnWJ+rvKcD7Diqg@mail.gmail.com>
To: www-voice <www-voice@w3.org>
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



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
Received on Thursday, 19 January 2012 17:29:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:42 UTC