Return-Path: 
 <commons-dev-return-102028-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 14902 invoked from network); 25 May 2007 14:41:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 25 May 2007 14:41:06 -0000
Received: (qmail 42495 invoked by uid 500); 25 May 2007 14:41:10 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 42287 invoked by uid 500); 25 May 2007 14:41:09 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 42275 invoked by uid 99); 25 May 2007 14:41:09 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 May 2007 07:41:09 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of ingmar.kliche@googlemail.com
 designates 209.85.132.242 as permitted sender)
Received: from [209.85.132.242] (HELO an-out-0708.google.com) (209.85.132.242)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 May 2007 07:41:02 -0700
Received: by an-out-0708.google.com with SMTP id d31so231100and
        for <commons-dev@jakarta.apache.org>;
 Fri, 25 May 2007 07:40:30 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=googlemail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
        b=W9GmXLSZ9o84AJT0QrO1AtSUCvq8mpSxDPjeFm4ZY8sY6Yu2JySlX305lNUGrIZSl/ELHUyHWkP1ld1HSsRFcwxXmW/pCsx2036l+bykcgmN0Ep6ISFocolVToXVKvSC6dJg6zlkU0fT/5/OkGJkLjlHbkzTngb4tudmsND7ujM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=fz47YpZzknzdGwSXRN0FeIHeGx/ZmGLTjOF4zBqONlBDyM/5rDXFDEw+LQnp9+WR9lY1Zcckn4+1OD+2XFpvsqvqpwyZRlxdxp+dgrFo99WZtAbFKKS9gFHsDo0WTIWLrL9Js2I5hP3YARczJZh6aOZghd4tHAPNwxCw50NzNoo=
Received: by 10.114.156.1 with SMTP id d1mr1524692wae.1180104025988;
        Fri, 25 May 2007 07:40:25 -0700 (PDT)
Received: by 10.115.74.12 with HTTP; Fri, 25 May 2007 07:40:25 -0700 (PDT)
Message-ID: <cc9610990705250740i28f7b6b3pf4ed0c30052ddf8b@mail.gmail.com>
Date: Fri, 25 May 2007 16:40:25 +0200
From: "Ingmar Kliche" <ingmar.kliche@googlemail.com>
To: commons-dev@jakarta.apache.org
Subject: [SCXML] Bug on decision of transition?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_167751_27414852.1180104025952"
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_167751_27414852.1180104025952
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I noticed that commons-scxml executes multiple transitions on one event as
soon as multiple transitions (i.e. multiple transitions exist for one event)
match. The SCXML spec instead says that only one transition has to be taken
(the first in document order) as long as it is not a parallel construct. To
illustrate this behavior I modified the state chart of the stop watch
example to

<scxml xmlns="http://www.w3.org/2005/07/scxml"
       version="1.0"
       initialstate="init">
...
 </state>
    <state id="reset">
*        <transition event="watch.start" target="running"/>
        <transition event="watch.start" target="stopped"/>
*        <transition event="watch.split">
         <assign name="foo" expr="3"/>
        </transition>
    </state>
....

I.e. the reset state contains two transitions for the event "watch.start".
According to the SCXML spec I would assume that the first transition in
document order will be taken, but commons-scxml executes both transitions
and ends up in two states. See the following log:


25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError
WARNUNG: NON_DETERMINISTIC (Multiple conflicting transitions enabled.):
[transition (event = watch.start, cond = null, from = /reset, to =
/stopped), transition (event = watch.start, cond = null, from = /reset, to =
/running)]
25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError
WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): <SCXML> :
[/running, /stopped]
25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError
WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): <SCXML> :
[/running, /stopped]
25.05.2007 16:27:01 org.apache.commons.scxml.SCXMLExecutor logState
INFO: Current States: [running, stopped]

Is this behaviour inteted?

Thanks and regards,
Ingmar

------=_Part_167751_27414852.1180104025952--