Re: SCXML: discrepancy in the standard?

Volker,

As more of an outside observer than a participant in these standards
discussions, I generally don't comment. But your last comments come across
as more of an unnecessary personal attack than a constructive criticism. I
guess I'm a technical guy (was a prof of EE and CS and wrote a technical
book on computer pattern recognition and many papers) and a past
management guy (manager of the Computer Science Division of an aerospace
company, founder and CEO of a speech recognition company) and am now an
independent analyst (223 monthly issues of Speech Strategy News so far),
and I occasionally still come up with algorithms and patents for
consulting clients. So, in my mind, being a "manager" doesn't mean you
cease being technical, and I've never associated management with politics.
(If anything, a manager often doesn't have the luxury of taking a
political stance if it means compromising getting something done.)

You weaken your insightful comments by taking them beyond the technical
level. 

- Bill

Bill Meisel
President, TMA Associates
Editor, Speech Strategy News






On 1/19/12 8:53 AM, "vs@spinke.de" <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 Friday, 20 January 2012 17:32:00 UTC