Issue - 287 - Uniqueness of Scope Names

[ws-bpel issues list editor <peter.furniss@erebor.co.uk>]

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 - 287 - Uniqueness of Scope Names

Status: received
Date added: 14 May 2006
Date submitted: 12 May 2006
Submitter: Dieter Koenig1
Document: WS-BPEL 2.0 Committee Draft, sections 10.1. and 12.4.3.
Description:

Background: the original objective of issue 162 was to avoid ambiguities for the <compensateScope> activity. If the <compensateScope> activity is not present, there is no need for any constraint, so the following example is perfectly acceptable:

   scope
      pick name="Pick"
         onMessage
            assign name="PopulateVariableX"
         onMessage
            assign name="PopulateVariableX"
As a result of the amended resolution of issue 162 : Unique Activity Names for Compensate ,
section 10.1. defines that "The name of a named activity MUST be unique amongst all named activities present within the same immediately enclosing scope. This requirement MUST be statically enforced.".

There is no definition of "immediately enclosed activities", and the text is not clear enough as scopes only have one primary activity. If all (transitively) "enclosed activities" were meant then the sentence would imply that the names of all named activities in a process must be unique, which was not the intention of 162.

As a result of the resolution of issue 275 : "immediately enclose" and compensation , section 12.4.3. now defines that "For the purpose of specifying the semantics of <compensate> and <compensateScope>, a scope, A is considered to immediately enclose another scope, B, if B is enclosed in A and B is not enclosed in any other scope or FCT-handler that is itself enclosed in the outer scope A. Other structured activities (e.g. <sequence> or <forEach>) and event handlers enclosed in A do not affect the concept of immediate enclosure".

This definition is VERY CLOSE to what is really needed as a resolution for 162. It should be made clear that the concept of an "immediately enclosed" scope includes scopes that result from the <invoke> shorthand notation for fault handlers and compensation handlers.
Submitter's proposal:

Note: the TC should be aware that the following proposal partially reverses the amendment of 162 in restricting the constraint to scopes only.

1. Replace the quoted sentences from section 10.1. by a reference: "See section 12.4.3. for uniqueness constraints of the name attribute."

2. Add to the quoted sentence in section 12.4.3.: "This definition includes scopes that result from the <invoke> shorthand notation for fault handlers and compensation handlers. Within a scope, the name of all named immediately enclosed scopes MUST be unique. This requirement MUST be statically enforced."

Changes: 14 May 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 - 287 - [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 - 287 - 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).