[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 69 - Proposal to vote
Maciej, If I read your proposal correctly, I agree
with you. The boundary crossing notion needs to be strengthened to include
usage of links relative to the definition, not just having the source and
target on different sides of the boundary. This would prohibit usage of a link
(entirely) inside a while loop when its definition is outside, thus making the
offending example illegal. This makes sense because of the very essence of issue
69 which points out that status lifetime is an important aspect of link
semantics – and the point of the boundary crossing prohibition rules was
that the construct boundary defines the limits of the meaningful use of a link
and the use of a link includes the lifetime of its status. Satish From: Maciej
Szefler [mailto:mbs@fivesight.com] Apropos the example in
the conference call: <flow
name="F1"> <link
name="l" /> <while
name="W1">
<flow name="F2"> <empty
name="E1">
<source link="l"/>
</empty>
<empty name="E2">
<target link="l"/> </empty>
</flow>
</while> </flow> The above should be
considered illegal. Unfortunately, after re-reading the spec it seems it is
currently legal. The current definition of crossing link boundaries is
at fault; it reads: "In general, a link
is said to cross the boundary of a syntactic construct if the source activity for the link is
nested within the construct but the target activity is not, or vice versa, if
the target activity for the link is nested within the construct but the source
activity is not." The definition
should should be changed to read: "In general, a
link is said to cross the boundary of a syntactic construct if the source or target activity for the
link is nested within the construct while the link is defined outside the
construct" The above example can of
course be rewritten to comply with the modified definition by moving the
link down to the more "appropriate" location: <flow
name="F1"> <while
name="W1">
<flow name="F2"> <link
name="l" /> <empty
name="E1">
<source link="l"/>
</empty>
<empty name="E2">
<target link="l"/> </empty>
</flow>
</while> </flow> The new definition is
more restrictive, but all expressions that were legal with the previous
definition will either remain legal, or can be rewritten as the above to make
them legal. With the new definition the proposed solution to 69 works and
has no possibilities for ambiguity regarding the value of a link status in
while loops: defining "l" in "F1" would
make it cross the while loop which is verboten, defining it in F2 means it will
unambiguously get reset with each iteration. Yaron's also pointed out
that links may not belong in <flow> activities. I agree;
they should belong inside scopes. For example: <scope> <link
name="l1" /> <link
name="l2" /> <sequence>
<switch>
<case condition="foo">
<empty name="E1">
<source link="l1" />
</empty>
</case>
<case condition="bar">
<emty name="E2">
<source link="l2" />
</empty>
</case>
</switch>
<empty name="E3" >
<empty name="E4" supressJoinFailure="true" >
<target link="l1" /> </empty>
<empty name="E5" suppressJoinFailure="true"> <target
link="l2"/> </empty> </scope> In the above the links
"l1" and "l2" are used to to propagate the results of the
choice in the <switch> activity down to activities E4 and E5 later in the
sequence. There is no flow, but still links come in handy. The alternative
(without links) would require the introduction of a variable to note which
control path was taken in the <switch> and the nesting of E4 and E5 in
switch statements of their own. Links allow us to express control flow
dependencies clearly in this case (i.e. E4 executes if E1 executed and E5
executes only if E2 executed). Note that we cant's simply move E4 and E4
into the switch statement in this case wihtout upsetting the requirement that
E4 and E5 execute only after E3. Links are very much tied
up with scopes in any case: scope faults cause links to be set false,
and non-permeable scope semantics (if we adopt them as we should) marries
the setting of link status to successful scope completion. Making this
relationship between links and scopes explicit is natural and would only
simplify the specification of precise link semantics. -Maciej From: I propose that we follow
Yuzo's suggestion for the resolution of this issue (his variant C).
Specifically, I propose that we add the following language to the fourth
paragraph of Section 12.5.1 The status of a link is not
set and not available for use when the immediately enclosing flow activity,
within which it is declared, starts. The status may be set during the
course of the immediately enclosing flow activity, and that status then
persists for the lifetime of that flow activity. However, if the same
(syntactic) flow activity is started again, for instance by virtue of being
inside a while loop, then the status of all links declared directly within it
is reset and is again not available for use at the start. Thus the
lifetime of the status of a link is exactly the lifetime of the immediately
enclosing flow activity within which it is declared. Satish |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]