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
|