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

Re: Child states exited, not re-entered after targetless transition in parent state

From: Zjnue Brzavi <zjnue.brzavi@googlemail.com>
Date: Wed, 26 Mar 2014 14:22:15 +0000
Message-ID: <CABmmmmwzVHhwdvXFvQsgwMo9-QJREz_cVRWqv_1TcfksExJxxQ@mail.gmail.com>
To: "www-voice@w3.org" <www-voice@w3.org>
Works a treat, thanks!

function computeExitSet(transitions)
>    statesToExit = new OrderedSet
>      for t in transitions:
>        if(getTargetSet(t.target))
>           domain = getTransitionDomain(t)
>           for s in configuration:
>              if isDescendant(s,domain):
>                statesToExit.add(s)
>    return statesToExit
>
>
> While we're at it, we should also change getTransitionDomain so that it
> returns null for a targetless transition.  This isn't strictly needed,
> given the new version of computeExitSet, but the current version returns
> the source state of the transition for targetless transitions.  If the
> targetless transition is a child  of a <parallel> element, this will be the
> <parallel> element, but getTransitionDomain is supposed to return a
> compound state.
>
> function getTransitionDomain(t)
>   tstates = getTargetStates(t.target)
>   if not tstates
>       return null
>     elif t.type == "internal" and isCompoundState(t.source) and
> tstates.every(lambda s: isDescendant(s,t.source)):
>       return t.source
>   else:
>       return findLCCA([t.source].append(tstates))
>
>
>
> On 3/25/2014 6:29 PM, Zjnue Brzavi wrote:
>
>> Hi,
>>
>> I've noticed a problem with test403b where event2 is never matched in
>> state p0s1.
>> On closer inspection it appears that the interpretation algorithm
>> currently causes p0s1 and p0s2 to exit when p0's inner transition is taken,
>> but they are not re-entered thereafter.
>>
>> Given p0's inner transition is targetless, should p0s1 and p0s2 be exited
>> in the first place?
>>
>> Thanks,
>> Zjnue
>>
>
> --
> Jim Barnett
> Genesys
>
>
Received on Wednesday, 26 March 2014 14:22:42 UTC

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