Alex,
We discussed 241 at least twice
during
the f2f. I've cut and pasted the notes from the minutes for the two
discussions that were recorded below. I don't recall any email from
the final discussion although we seemed to have a consensus among the
attendees.
Hope this helps.
First discussion on Jan 11
Issue 241
Resolution proposal at: http://lists.oasis-open.org/archives/wsbpel/200509/msg00083.html
(to simplify, I did not inlcude
the entire text of the proposal from the link above which is in the
minutes)
Rania: can someone clarify
resolution
(b) and (c)
Chris: The issue is; since onEvent
is
behaving like a scope add all the attributes of scope on onEvent.
Diane: Should we ask Danny to make
(c)
as a separate issue. Yes?
Simon: yes
Monica: yes
Alex: what is the difference
between
(a) and (b)
Chris: there seems to be no
difference
Rania: yes no difference
Alex: Let’s discuss the issue and
resolution
Dieter: Issue 126 is related to
this
where Yaron has defined some scenarios
Diane, is this the resolution?
Alex: partnerlink resolved to
local
scope first and then ancestor scope
Correlation: same as partnerlink
Variable and messageexchange
resolved
to the associated scope only
Chris: Yes messageExchange should
be
resolved like a variable. First as local and then in the ancestor scope
Dieter: Why ancestor?
Chris: Don’t know
Alex: Should we limit this to
local
only. There seems to be no compeling reason.
Yuzo: I think it should be uniform
Chris: I agree
Alex: It can cause problems for
onEvent
Alex: I am only referring to
onEvent
Alex: We always miss the onEvent
description
when working on the spec.
Alex: fromPart and toPart
variables
are implicit so we don’t need to worry about it because it is local
scope.
Simon:
OnEvent scope resolution:
PartnerLink resolved to local
scope first and ancestor scope
Correaltion: same as partnerlink
MessageExchange: same as
partnerlink
Variables ( frompart and
topart):
Local scope only
Alex: Dieter would like to
collapse
onEvent and Scope so we don’t need to invoke to have a separate
declaration
of scope inside onEvent
Second discussion on Jan 12
Issue 241:
Alex: Yesterday, we came to a
set
of
resolution rules
Questions regarding syntax: do
we
want
to collapse onEvent and scope? If we do that it would be more backward
compatible with v1.1
Diane: Is there any example how
this
can be done?
Alex: Danny sent an example.
Alex: In v1.1 we are talking
about virtual
scopes. But it is getting complicated in v2.0. According to 204 onEvent
must have a scope as the child activity.
Chris: If we collapse do we
have
to declare
some elements? Probably we may save some declarations.
Alex: There is no difference.
The
order
may change. I do not have any preference.
Chris: The current syntax for
onEvent
– the collapsing would eliminate the messageType
Dieter: Here is an example how
it
could
look like. tOnEventScope inherits from bpws:tScope
Alex: The question is do we
want
to be
backward compatible, do we want to save some declarations?
Allen: It is also important to
be
understandable.
Chris: Binding rules play
important role.
If we say that the child activity is scope and change the binding then
the correlation set will follow the same logic. So this has to be
cleaned.
Alex: If we want to do clean up
the syntax
will not be backward compatible. That reason does not hold. Maybe we do
not want to collapse.
Allen: Explicit scope is more
understandable.
Alex: So, onEvent must have an
explicit
scope. I believe we understand the direction.
Dieter: For foreach the scope
element
is also mandatory child element. So onEvent is not the only place
Diane is recording the sense of
the committee:
do not collapse – we cannot maintain backward compatibility and also
for
the forEach activity we require scope as the only activity that can be
included and it would be hard to collapse forEach and scope.
Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
----- Forwarded by
Diane
Jordan/Raleigh/IBM on 02/08/2006 10:26 PM -----
Hi Danny,
Few quick things:
- I would suggest that we should work on the
proposal (maybe
directional) on Issue 241 first regardless of how syntax is resulted
from
Issue 242. Note: 241 is just about <onEvent> resolution
semantics,
while 244 covers both <onEvent> and <forEach> syntax.
I guess you would feel OK with this approach?
- We spent a hour or so in discussing 241 during
F2F. There
has been already a preliminary consensus in terms of how resolution
rules should be applied to Issue 241. Unfortunately, I could not find
the
email that recap the consensus. :-( ... I will try to recall it from my
memory and send out an email of that preliminary recap later
in the email thread of issue 241.
- For Issue 241 and particularly
Issue 242,
we need to address <fromPart> usage in <onEvent>, which you
have not mentioned in your previous email.
- After browsing your email quickly, my current
preferences
about variable resolution (about variable declaration and reference)
are
somewhat different from your current preference. Let's discuss it over
Issue 241 thread.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
When I started 242, I was only intending to coalesce
syntax,
and leave all semantics alone. But as I look at 241, I realize that
242 gives us a great opportunity to actually fix some stuff that is
unclear
at best, and most likely broken.
Currently, an onEvent looks like (for clarity, only relevant portions
are
included):
<onEvent partnerLink="ncname"
messageType="qname" variable="ncname"
messageExchange="ncname"? >*
<correlationSets>?
<correlationSet
name="ncname"
properties="qname-list"/>+
</correlationSets>
<correlations>?
<correlation set="ncname"
initiate="yes|join|no"?/>+
</correlations>
scope-activity
</onEvent>
Resolution/declaration occurs as follows:
partnerLink - reference - resolved to parent scope - no ability to
declare
on onEvent
correlation - reference resolved to onEvent/correlationSets - (note
that
this doesn't mean that the correlationSet be actually defined there,
just
that that's the resolution scope)
correlationSets - declaration - may be used by correlation, or nested
activities
variable - reference AND declaration - variable and messageType/element
constitute a declaration; variable alone constitutes a reference
(to itself).
messageExchange - I'm not sure - Alex's interpretation (in 241)
conflicts
with mine. I'll try to present them both, and apologies to Alex if
I don't present his side well.
Alex: "messageExchange: resolved to the associated scope only."
What Alex seems to me to be saying here is that the messageExchange
is both a declaration and a reference. This would be true for both
the presence of a messageExchange, as well as the absence of one, due
to
our Default Message Exchange (DME) provided by onEvent. Thus an IMA
has no possibility of crossing eventHander boundaries (in either
direction).
Danny: the messageExchange attribute is only a reference. As
such, technically it resolves to the associated scope, since the
associated
scope has a DME. In reality, it resolves to a parent scope, if
specified;
and if not specified, it resolves to the associated scope.
In 242, I propose that an eventHandler look like this (again, only
including
the relevant parts for clarity):
<onEvent partnerLink="ncname"
messageType="qname"? variable="ncname"
messageExchange="ncname"?>*
<correlationSets>?
<correlationSet
name="ncname"
properties="qname-list"/>+
</correlationSets>
<correlations>?
<correlation set="ncname"
initiate="yes|join|no"?/>+
</correlations>
<partnerLinks>?
</partnerLinks>
<variables>?
</variables>
<messageExchange>?
</messageExchanges>
activity
Option 1: We can keep the exact same resolution semantics.
Option 2: Make all attributes be references only, with resolution
on the onEvent scope (the messageType attribute would be removed):
Resolution/declaration occurs as follows:
partnerLink - reference - resolved to onEvent's <partnerLinks>
element.
This is a change, since there was no ability to have a
<partnerLinks>
element.
partnerLinks - declaration - may be used by correlation, or nested
activities
- no change
correlation - reference resolved to onEvent/correlationSets - (note
that
this doesn't mean that the correlationSet be actually defined there,
just
that that's the resolution scope) - No change
correlationSets - declaration - may be used by correlation, or nested
activities
- no change
variable - reference ONLY. variable resolves to onEvent's
<variables>
element. If no variable is declared there, then resolves to parent,
as would be natural. This is a
semantic change.
variables - declaration - may be used by variable attribute, or nested
activities - The use by the variable attribute is a semantic change
messageExchange - reference ONLY. resolves to onEvent's
messageExchanges.
If no variable is declared there, then resolves to parent, as would
be natural. This may or may not
be a semantic change, depending on your previous interpretation.
Option 3: Option 2 with backward compatibility of messageType/element
attribute:
variable - if
messageType/element
present, then variable is a reference AND a declaration as before. If
messageType/element are not present, then use Option 2 resolution rules.
ws-bpel issues list editor wrote:
This issue has been added to the wsbpel issue
list
with
a status of "received". The status will be changed to "open"
if a motion to open the issue is proposed and that motion is approved
by
the TC. A motion could also be proposed to close it without further
consideration.
Otherwise it will remain as "received".
The issues list is posted as a Technical
Committee
document
to the OASIS
WSBPEL TC pages on a regular basis. The
current
edition, as a TC document, is the most recent version of the document
entitled
in the "Issues" folder of the WSBPEL
TC document list - the next posting as a
TC
document will include this issue. The list editor's working copy, which
will normally include an issue when it is announced, is available at this
constant URL.
Issue - 242 - Remove required scope children
Status: received
Date added: 21 Jan 2006
Categories: Scoping,
Syntax
Date submitted: 20 January 2006
Submitter: Danny
van der Rijn
Description: Arising from part (B) of [proposed
resolution;MSG=200509/83]
for issue
120.2
and its discussion. See http://lists.oasis-open.org/archives/wsbpel/200509/msg00083.html
Rescind issue
204 : clarify the relationship between eventHandler and
compensationHandler 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 (
issue 241)
issue 241 :
clarification
of onevent resource resolution was for
onEvent.
This issue is for onAlarm and forEach
Changes: 21 Jan 2006 - new issue
To comment on this issue (including whether it
should be
accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org
list (replying to this message should automatically send your message
to
that list), or ensure the subject line as you send it starts
"Issue
- 242 - [anything]" or is a reply to such a message. If you want to
formally propose a resolution to an open issue, please start the
subject
line "Issue - 242 - Proposed resolution", without any Re: or
similar.
To add a new issue, see the issues procedures
document
(but the address for new issue submission is the sender of this
announcement).
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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