You aren't missing anything. I think the proposed algorithm will not put
is in an invalid configuration as far as exit states are concerned. It
just decides exit sets on one criteria and then preemption on another
criteria; an inconsistency that will be difficult for an end use of the
system to decipher.
In the end this may just be a judgement. Doing preemption based off of
arenas provides an answer consistent with how to generate exit sets in the
first place. Doing it off of source will match UML closer.
I think source is a poor technical choice but it will work. As I think
exit sets is a poor technical choice, but they will work. They will both
just lead to more questions and more bugs in implementation later down the
road than a short definition based off of arenas but this is the path that
you are absolutely dead set to go down.
Chris
On Fri, Mar 8, 2013 at 12:41 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:
> By â€˜correctnessâ€™, I mean that the preemption algorithm will never put us
> in an illegal state configuration. As far as I can tell, as long as we
> detect conflicts correctly, then we can use any heuristic we want to
> resolve conflicts, including flipping a coin, and the algorithm will be
> â€˜correctâ€™. Unless Iâ€™m missing something, the issues with preemption
> heuristics are whether they are clear, or intuitive, or consistent with
> UML, etc. ****
>
> ** **
>
> **- **Jim****
>
> ** **
>
> *From:* chris nuernberger [mailto:cnuernber@gmail.com]
> *Sent:* Friday, March 08, 2013 1:27 PM
>
> *To:* Jim Barnett
> *Cc:* VBWG Public (www-voice@w3.org)
> *Subject:* Re: more on preemption****
>
> ** **
>
> I don't have time right now. The error isn't in calculating the exit sets
> but specifically in deciding how to preempt things.****
>
> ** **
>
> The error is line:****
>
> if isDescendent(t1.source, t2.source):****
>
> transitionsToRemove.add(t2)****
>
> else:****
>
> t1Preempted = true****
>
> break****
>
> ** **
>
> Where it reads t1.source and t2.source is should be getArena(t1) and
> getArena(t2).****
>
> ** **
>
> Chris****
>
> ** **
>
> ** **
>
> On Fri, Mar 8, 2013 at 11:20 AM, Jim Barnett <Jim.Barnett@genesyslab.com>
> wrote:****
>
> Chris,****
>
> Are you saying that we are calculating exit sets incorrectly? The
> algorithm detects a conflict between two transitions whenever their exit
> sets intersect. Thereâ€™s no mention of source states here (i.e., in the
> definition of conflict) except insofar as they help determine the exit set.
> ( Internal transitions are handled in getTransitionDomain(), so their
> influence on the exit set should also be reflected in the algorithm) Then
> once a conflict is detected, we look at the source state relationships to
> determine who preempts whom. Thatâ€™s our heuristic for resolving
> conflicts, inherited from UML, but I donâ€™t think it effects correctness.
> But if weâ€™re calculating exit sets incorrectly, that would cause us to be
> incorrect. ****
>
> ****
>
> Can you send around an example that shows the problem?****
>
> ****
>
> Thanks,****
>
> Jim****
>
> ****
>
> *From:* chris nuernberger [mailto:cnuernber@gmail.com]
> *Sent:* Friday, March 08, 2013 1:07 PM****
>
>
> *To:* Jim Barnett
> *Cc:* VBWG Public (www-voice@w3.org)
> *Subject:* Re: more on preemption****
>
> ****
>
> I don't think the algorithm is correct. This goes back to the UML spec
> which I *also* think is incorrect.****
>
> ****
>
> This argument ignores transitions of internal types which is a detail.****
>
> ****
>
> The exit set is calculated via the LCCA of the source and the target
> states. Let's call this item the transition arena as we have before.****
>
> ****
>
> It may be the source but it also may be considerable higher up the state
> graph than the source.****
>
> ****
>
> Your given algorithm only compares the transition sources for descendant
> qualities when it should compare the transition arenas *because* the
> sources may be unrelated in the graph *but* the exit sets collide. A
> correct algorithm would look *just* like the one given except you would
> compare the transition arena's for descendent instead of transition sources.
> ****
>
> ****
>
> Chris****
>
> ****
>
> ****
>
> ****
>
> On Fri, Mar 8, 2013 at 8:12 AM, Jim Barnett <Jim.Barnett@genesyslab.com>
> wrote:****
>
> There hasnâ€™t been any further discussion on this. Based on the discussion
> so far, I think that we should say that transitions in descendents preempt
> transitions in ancestors.) The UML spec requires this quite clearly (even
> if the rest of the discussion is confusing) and â€œdescendents preempt
> ancestorsâ€