this made the scripts revert the status of issue 10 from resolved to "resolution proposed". Since a second vote is being proposed, I've left that as the status and renamed the "Resolution" as "Original resolution", with a bit of explaining text.
Peter
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: 08 September 2004 21:24
> To: wsbpeltc
> Cc: Furniss, Peter
> Subject: Issue 10 - Proposal to vote
>
>
> Playing both sides of Peter's subject-line script -- haven't
> done this for a while ..
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, September 08, 2004 1:21 PM
> To: wsbpeltc
> Subject: [wsbpel] Proposal to vote - Issue 10
>
> I would like to see this issue resolved by the upcoming F2F.
> To start that process here is the formal proposal to vote.
> Comments welcome as usual.
>
> The formal proposal simply collates the note I sent this
> morning with the strawman I posted some time ago.
>
> Starting point:
>
> Recall that at one point I had suggested that we make
> "reversibility" an explicit attribute of scopes and require
> that all reversible scopes are also isolated. This would
> have solved the problem of default compensation order by
> creating (and therefore forbidding) cycles when links cross
> reversible scope boundaries in both directions. There were
> concerns with that proposal having to do with the complex
> state semantics of non reversible scopes, nesting of isolated
> scopes, etc., which caused me to withdraw that proposal. We
> continue to treat all scopes as being reversible, but of
> course we cannot make all scopes isolated.
>
> The new proposal essentially amounts to simply separating the
> cycle detection consequences of the old one and making that
> an explicit restriction. In other words, the simple way to
> state the proposal (at least my intent in formulating it,
> modulo any mistakes I made) is that we should treat all
> scopes as if they were isolated *but only for purposes of
> cycle detection regarding links crossing scope boundaries*.
>
> Proposal:
>
> I begin with a formal restatement for Part II of the
> resolution of Issue 10. I will then add some explanation.
>
> Definition: Peer-Scopes. Two scopes S1 and S2 are said to be
> peer scopes if they are both directly nested within the same
> parent scope (including process scope).
>
> Definition: Scope-controlled set. An activity A is within
> the scope-controlled set of activities of scope S if either A
> is S itself, or A is nested within S, at any depth.
>
> Definition: Peer-Scope Dependency. If S1 and S2 are peer
> scopes then we say that S2 has a direct peer-scope dependency
> on S1 if there is an activity B within the scope-controlled
> set of S2 and an activity A within the scope-controlled set
> of S1 such that B has a control dependency on A. The
> peer-scope dependency relation is the transitive closure of
> the direct peer-scope dependency relation.
>
> Part II: The peer-scope dependency relation MUST NOT include
> cycles. In other words, BPEL forbids a process in which
> there are peer scopes S1 and S2 such that S1 has a peer-scope
> dependency on S2 and S2 has a peer-scope dependency on S1.
>
> Explanation:
>
> The basic motivation for Part II is to make the "respect for
> control dependency" rule of Part I consistent with a
> depth-first traversal of the scope tree for default
> compensation. If we can guarantee that there is a
> depth-first (post-order variant) traversal consistent with
> Part I, we no longer have any difficulty in defining default
> compensation of any scope, since depth-first order implies
> that such compensation is only dependent on the compensation
> of its nested scopes. The question then reduces to
> constraining control paths so we can make this guarantee. I
> claim that we need only concern ourselves about control
> dependencies between peer scopes in the sense defined above.
> An example illustrates the point. Consider the following
> example (taken from an earlier exchange with Alex)
>
> <scope name="s0">
> <scope name="s1">
> <flow>
> <anActivity> <source linkName="lnk1" /> </anActivity>
> <!-- Assume that the above anActitity does
> not contain a
> scope activity -->
> <scope name="s2">
> <target linkName="lnk1" />
> </scope>
> </flow>
> </scope>
> </scope>
>
> Does the link create a dependency between s1 and s2 that has
> any relevance to compensation order? If this example is changed to
>
> <scope name="s0">
> <scope name="s1">
> <flow>
> <scope name="s7">
> <source linkName="lnk1" />
> </scope>
> <scope name="s2">
> <target linkName="lnk1" />
> </scope>
> </flow>
> </scope>
> </scope>
>
> Does the situation change? The only difference between the
> examples is that, whereas s1 was theoretically responsible
> for the compensation of the previous generic anActivity
> (since we assumed it does not contain a scope), it's
> replacement scope is an activity that is responsible for its
> own compensation. But let us look further. If we think
> about default compensation behavior for s1 it is going to do
> absolutely nothing about compensating any non-scope
> activities nested inside it. Thus the fact that fact that s1
> was theoretically responsible for the compensation of the
> generic anActivity has no consequence regarding a required
> ordering of compensation between s1 and s2. Part II exploits
> this point and its generalization to control chains and
> multiply nested scopes.
>
> Satish
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php.
>
>
