Issue - 302 - Declarations that hide others in Executable Completion of Observable Behavior Profile

[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 - 302 - Declarations that hide others in Executable Completion of Observable Behavior Profile

Status: received
Date added: 21 Jun 2006
Date submitted: 19 June 2006
Submitter: Danny van der Rijn
Description:

While reviewing the text that was dropped from the observable behavior executable completion rules, it looked to me like a rule was missing. From the current section (omitted from the spec by mistake, and sent out by Rania a little while ago):

> "Data writing may cause changes in interaction order. Changes caused by data writing are not enforced by the completion rules, but are highlighted here as an advisory note. One example is changing the value of a variable used in a condition that affects branching, in such a way that the new effective branching behavior is in direct conflict with what is specified by the abstract process. Conditions that affect the flow of control such as transition conditions, “if-then” or “while” expressions, among others, can have such an effect on the order of interactions. For example, adding a new <while> loop with a “true” condition as a child of an existing <sequence> would hang the process. "
Following later is a list of bullets of things that are disallowed in the Executable Completion.  (summarized here)

• can't add new interactions with existing partnerlinks.
• can't change EPRs of existing links, or copy them to new ones.
• can't change parent of any existing activity
• can't add new branches to an if-then, pick, can't add FCT-handlers to a non-process scope, can't add exit activity
• can't add an activity that would throw a non-standard fault to an existing activity

Submitter's proposal: I propose adding a restriction on declaration hiding after the 2nd bullet:
> New variable or partnerLink declarations that would hide existing ones, MUST NOT be used, as such declarations could change the branching behavior or existing partnerLink interactions.

Changes: 21 Jun 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 - 302 - [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 - 302 - 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).