Re: SCXML: discrepancy in the standard?

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 16:59:18 UTC