Hi Danny,
“The onEvent now has all of the elements and
attributes of <scope> except: suppressJoinFailure and
standard-elements. They make no sense, as they deal with links, which are
disallowed to and from <onEvent>. I left off "isolated"
because I didn't think it was relevant. I'm open to discussion on this.”
I think we should keep the ‘isolated’
attribute. <onEvent> are always in the context of concurrency, so it
would be helpful to be able to synchronize the <onEvent> as a unit,
instead each of its nested activity (e.g. sequence, flow) and declarations (e.g.
fault handlers, compensation handlers, etc)… Before it was not such a big
deal, as there could only be nested activity, but no nested declarations.
Regards,
Alexandre
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, September 30, 2005
2:24 PM
To: wsbpeltc
Subject: [wsbpel] Re: Issue 120.2
- Proposal For Vote
Part A: (treat as 120.2.1)
Proposal:
Rescind 204 and change its resolution to no longer require that the child
activity within an <onEvent> be a <scope>. Additionally:
onEvent syntax shall be:
<onEvent name="ncname"? partnerLink="ncname"
portType="qname"?
operation="ncname"
variable="ncname"
messageExchange="ncname"? >*
<correlationSets>?
<correlationSet name="ncname"
properties="qname-list"/>+
</correlationSets>
<correlations>?
<correlation set="ncname"
initiate="yes|join|no"?/>+
</correlations>
<fromPart part="ncname" toVariable="ncname"/>*
<!-- added from scope -->
<partnerLinks>?
... see above under <process> for syntax ...
</partnerLinks>
<variables>?
... see above under <process> for syntax ...
</variables>
<faultHandlers>?
... see above under <process> for syntax ...
</faultHandlers>
<compensationHandler>?
... see above under <process> for syntax ...
</compensationHandler>
<terminationHandler>?
...
</terminationHandler>
<eventHandlers>?
...
</eventHandlers>
<messageExchange>?
...
</messageExchanges>
<!-- end of things added from scope -->
activity
</onEvent>
For the elements that are marked as "added from scope", the syntax
and semantics shall be the same as they are defined in <scope>. The
syntax and semantics of <messageExchanges> as TBD as defined in Satish's
resolution to Issue 123.
These elements may be referenced by attributes defined on the
<onEvent>. I.e. the partnerLink attribute may refer to a
<partnerLink> element defined inside <partnerLinks>. The same
holds true for messageExchange, when defined.
For purposes of resolving values referenced by onEvent attributes, partnerlinks
etc declared in the onEvent scope come first.
Rationale: Semantically, no changes have been made to the expressibility
of the <onEvent> element. However, syntactically, we no longer have
to deal with definining the variable and messageExchange in a way that is
different from how it is defined elsewhere, and possible "forward"
referencing. (We trade "lateral referencing" for "forward
referencing" - which isn't actually forward, it's
"downward") Nor do we have to deal with the anomaly of an
onEvent requiring a scope to be its child.
The onEvent now has all of the elements and attributes of <scope>
except: suppressJoinFailure and standard-elements. They make no
sense, as they deal with links, which are disallowed to and from
<onEvent>. I left off "isolated" because I didn't think
it was relevant. I'm open to discussion on this.
----------------------
If part A looks good to folks, then parts B and C can have verbiage
added.. I decided not to take the time, since I think it's fairly
obvious, and the intent here is to show people where my though processes are
going with 120.2 Note that A can happen independently of B or C.
Part B: (treat as 120.2.2)
Rescind 204 completely. Add the elements and attributes from scope
(except suppressJoinFalure, isolated, and standard-elements for onAlarm) that
are not currently on <onAlarm> and <forEach>
Rationale: Extend the relevant rationale from Part A
NOTE: This proposal probably depends on part A passing, but doesn't require
part C.
--------------------
Part C: (treat as 120.2.3)
Rescind 147.4 Re-resolve the other way: I.e. separate activities
for serial and parallel forEach. Part B would only apply to
parellelForEach if B is accepted as well.
Rationale: Serial and parallel forEach are semantically divergent.
They are getting more and more divergent syntactically. Cf. 204,
6.2, 216, 120.2.2, 227, and probably others. It is to the point where it
is easier to make them different and point out the similarities, than it is to
keep them the same and point out the differences.
NOTE: This is not dependent on either part A or part B.
Danny van der Rijn wrote:
As discussed at the F2F
this morning, here are my thoughts for solving 120.2, although I need to think
some more before I want this to come up for vote.
To take all of the attributes and elements that we care about (tbd later) from
scope and put them on onevent.
Allow partner links and, when introduced, message exchange attribute
declarations to be declared inside the onevent element, to be referenced by
attributes used by onevent.
For purposes of resolving values referenced by onevent attributes, partnerlinks
etc declared in the onevent scope come first.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |