Re: [wsbpel] Issue - 242 - Allow/require onEvent's variable to bedeclared in <variables>? (Also, issue 241)

[Danny van der Rijn <dannyv@tibco.com>]

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