WS BPEL issues list

This file last updated 22:20 28 Aug 2006 (UTC)

This is the final version of the main issues list for the OASIS Web Services Business Process Execution Language Technical Committee covering issues raised in the progresstion of the original input document to the Public Review text of WS-BPEL 2.0, in August 2006. A new issues list has been created for comments arising from the Public Review. Issues in that list are distinguished by starting with "R".

• Table of all issues, ordered by issueID
  
  
• Detailed list of issues. The issues in this list have anchors of the form "Issue1", "Issue22".

Procedures for handling of issues were defined in the issues process document, and the procedure for issues submitted after 15 August 2004.

It was resolved at the TC meeting on 19 July 2006 that any issues submitted after 21 July 2006 would not be considered for opening until the public review period had started. Only one issue was submitted during that period, and it has been transferred to review issues list.

All issues, in order

The colour of the issue title is determined by the status: green=transferred (1 issues), green=resolved (338 issues). (Those numbers count sub-issues as separate.) According to the TC issue procedures (issues process document), the formal status values are "open" and "resolved". The procedure revision for issues submitted after 15 August 2004 implies a provisional status before an issue is open. The other status values are just informational variations on those.

The "revisitable" entry applies to resolved issues where it has been suggested that it may be worth returning to the question in future work, after the completion of the first OASIS TC edition of the WS BPEL specification.

Issue 1: Permeability of scopes

This is the same proposal that was posted earlier (reproduced below for convenience) with one slight necessary clarification (pointed out by Alex).

Clarification:

The restriction that links cannot cross serializable scope boundaries is now no longer needed. Since serializable scopes are now impermeable, such links cannot cause deadlock. The proposal therefore is to eliminate this restriction. This was already implied in the previous proposal implicitly.

Original proposal restated: The core problem in Issue 1 is that we have no way to control the firing of links in cases where the source activity may be compensated after the link has fired and thus "revoke the promise" of prerequisite fulfillment that the link may represent.

The proposal is to strengthen the meaning of "variableAccessSerializable" to also control the visibility of link status, by attaching the meaning of isolation to the attribute. In order to reflect this we propose that the name of the attribute be changed to "isolated". Thus we would have

   <scope isolated="yes"> <!-- serializable, non-permeable -->
       <faultHandlers ...> ... </faultHandlers>
       <compensationHandler ...> ... </compensationHandler>
       ...
   </scope>


   <scope isolated="no"> <!-- non-serializable, permeable -->
       <faultHandlers ...> ... </faultHandlers>
       <compensationHandler ...> ... </compensationHandler>
       ...
   </scope>

Note that this gives the BPEL process designer the discretion to use isolated="no" when s/he cares to protect the target from revocable promises. The downside of the protection is potential loss of concurrency.
Links: Announcement, 25 Jun 2003     Satish Thatte, 15 Sep 2003     Discussed at Redmond face-to-face - Dieter's presentation (document details)     Ricky Ho, 25 Sep 2003     Satish Thatte, 17 Mar 2004     Reversible and Permeable Scopes v2.ppt (document details)     Satish Thatte, 16 Mar 2004     Danny van der Rijn, 16 Mar 2004     Yaron Y. Goland, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Frank Leymann, 19 Mar 2004     Discussed at Walldorf f-t-f (document details)     Goran Olsson, 28 Apr 2004     Satish Thatte, 29 Apr 2004     Nickolas Kavantzas, 7 May 2004     Proposed resolution (Satish Thatte, 7 Jun 2004)     Proposed resolution (Satish Thatte, 18 Jun 2004)     Issues 1 and 10.ppt (document details)
Changes: 4 Jul 2003 - fields: Document;    11 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    17 Mar 2004 - fields: Links;    19 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    8 May 2004 - fields: Links;    9 Jun 2004 - fields: Links, Status, Proposed resolution;    16 Jun 2004 - fields: Categories;    18 Jun 2004 - fields: Links, Status, Proposed resolution;    23 Jun 2004 - fields: Links, Status, Proposed resolution, Resolution;    6 Oct 2004 - fields: In spec

Issue 2: Sub-Functions

Proposed resolution: Ivana Trickovic, 24 Nov 2004
Resolution: Closed with no change to the specification at the F2F held 8 - 10 March 2005, Walldorf, Germany.

Links: Announcement, 25 Jun 2003     Eckenfels. Bernd, 22 Jul 2003     Kevin Liu, 22 Jul 2003     Assaf Arkin, 23 Jul 2003     Ivana Trickovic, 29 Oct 2003     Yaron Goland, 29 Oct 2003     Edwin Khodabakchian, 29 Oct 2003     Yaron Goland, 29 Oct 2003     Chris Keller, 30 Oct 2003     Nickolas Kavantzas, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Harvey Reed, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Harvey Reed, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Yaron Goland, 30 Oct 2003     Yaron Goland, 30 Oct 2003     Yaron Goland, 31 Oct 2003     Yaron Goland, 31 Oct 2003     Frank Leymann, 31 Oct 2003     Harvey Reed, 31 Oct 2003     Ivana Trickovic, 31 Oct 2003     Yaron Goland, 31 Oct 2003     Ron Ten-Hove, 1 Nov 2003     Yaron Goland, 3 Nov 2003     Yaron Goland, 3 Nov 2003     Yaron Goland, 3 Nov 2003     Satish Thatte, 5 Nov 2003     Satish Thatte, 5 Nov 2003     Ugo Corda, 5 Nov 2003     Satish Thatte, 6 Nov 2003     Ron Ten-Hove, 6 Nov 2003     Ugo Corda, 6 Nov 2003     Harvey Reed, 6 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Ugo Corda, 7 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Harvey Reed, 7 Nov 2003     Monica J. Martin, 10 Nov 2003     Ivana Trickovic, 10 Nov 2003     Eckenfels. Bernd, 12 Nov 2003     Ugo Corda, 12 Nov 2003     Ivana Trickovic, 14 Nov 2003     Yaron Goland, 25 Nov 2003     Edwin Khodabakchian, 25 Nov 2003     Assaf Arkin, 25 Nov 2003     Harvey Reed, 25 Nov 2003     Ron Ten-Hove, 25 Nov 2003     Ivana Trickovic, 26 Nov 2003     Peter Furniss, 26 Nov 2003     Eckenfels. Bernd, 26 Nov 2003     Post-Melbourne discussion on coordination questions is under issue 30 issue 30     Proposed resolution (Yaron Y. Goland, 16 Jun 2004)     Dieter Koenig1, 17 Jun 2004     Satish Thatte, 18 Jun 2004     Discussed at San Francisco f-t-f     Ivana Trickovic, 21 Jul 2004     Satish Thatte, 21 Jul 2004     Ivana Trickovic, 22 Jul 2004     Frank.Leymann@t-online.de, 23 Jul 2004     Yaron Y. Goland, 23 Jul 2004     Ivana Trickovic, 4 Aug 2004     Ivana Trickovic, 4 Aug 2004     Yaron Y. Goland, 6 Aug 2004     Ivana Trickovic, 27 Aug 2004     Yaron Y. Goland, 9 Sep 2004     Proposed resolution (Ivana Trickovic, 15 Sep 2004)     Ivana Trickovic, 21 Sep 2004     Ivana Trickovic, 23 Sep 2004     Maciej Szefler, 25 Sep 2004     Ivana Trickovic, 28 Sep 2004     Peter Furniss, 28 Sep 2004     Maciej Szefler, 28 Sep 2004     Maciej Szefler, 28 Sep 2004     Chris Keller, 29 Sep 2004     Proposed resolution (Ivana Trickovic, 24 Nov 2004)     Ivana Trickovic, 8 Dec 2004     Satish Thatte, 9 Dec 2004
Changes: 4 Jul 2003 - fields: Document;    22 Jul 2003 - fields: Links;    23 Jul 2003 - fields: Links;    24 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    30 Oct 2003 - fields: Links;    31 Oct 2003 - fields: Links;    1 Nov 2003 - fields: Links;    3 Nov 2003 - fields: Links;    5 Nov 2003 - fields: Links;    6 Nov 2003 - fields: Links;    7 Nov 2003 - fields: Links;    8 Nov 2003 - fields: Links;    10 Nov 2003 - fields: Links;    12 Nov 2003 - fields: Links;    13 Nov 2003 - fields: Links;    16 Nov 2003 - fields: Links;    26 Nov 2003 - fields: Links;    9 Dec 2003 - fields: Links;    2 Jun 2004 - fields: Champion;    16 Jun 2004 - fields: Links, Status, Proposed resolution;    17 Jun 2004 - fields: Links;    19 Jun 2004 - fields: Links;    24 Jun 2004 - fields: Links;    21 Jul 2004 - fields: Links;    22 Jul 2004 - fields: Links;    23 Jul 2004 - fields: Links;    4 Aug 2004 - fields: Links;    7 Aug 2004 - fields: Links;    27 Aug 2004 - fields: Links;    9 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    21 Sep 2004 - fields: Links;    23 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    29 Sep 2004 - fields: Links;    30 Sep 2004 - fields: Links;    24 Nov 2004 - fields: Links, Status, Proposed resolution;    8 Dec 2004 - fields: Links;    10 Dec 2004 - fields: Links

Issue 3: Current state influence in compensation handlers

Following is extracted from proposal message.

The relevant text in Section 13.3.1 will be replaced with the following, with appropriate editing (the picture (see attachment to proposal message) would also be included in the specification):

Compensation handlers always interact with the current state of the process, specifically the state of variables declared in their associated scope and all enclosing scopes. The variables include partnerLinks at the process scope. Compensation handlers are able to both get and set the values of all such variables. Other parts of the process will see the changes made to shared variables by compensation handlers, and conversely, compensation handlers will see changes made to shared variables by other parts of the process, including situations where a compensation handler runs concurrently with other parts of the process. Compensation handlers will need to use serializable scopes when they touch state in enclosing scopes to avoid interference.

The current state of the process consists of the current local state of all scopes that have been started. This includes scopes that have completed but for which the associated compensation handler has not been invoked. For completed uncompensated scopes their current local state is the state as it was at the time of completion. Such scopes are in suspended animation because their compensation handlers are still available and therefore their execution may continue in compensation mode. Note that a scope may have been executed several times in a loop, and the current state of the process includes the state of each completed (and uncompensated) iteration through the scope.

The behavior of a compensation handler can be thought of as an optional continuation of the behavior of the associated scope and as such its usage of variables is similar to the usage that occurred in the body of the scope itself, including update actions. This includes variables in both the local scope and all enclosing scopes. Note that the compensation handler may itself have been called from an enclosing compensation handler. It will then share the continuation of the state of the enclosing scope that its caller is using. In the attached picture showing three nested scopes S1, S2 and S3, and their compensation handlers C1, C2, C3, and failure handlers F1 and F2, we may have an error handling call stack F1->C2->C3. In that case C3 will share the state of S2 as it is being seen and used by C2.

Issue 4: Dynamic parallel processing

Closed with no change.
Links: Announcement, 25 Jun 2003     Yaron Y. Goland, 25 Mar 2004     Ivana Trickovic, 31 Mar 2004     Ivana Trickovic, 1 Apr 2005
Changes: 4 Jul 2003 - fields: Document;    31 Jul 2003 - fields: Champion;    25 Mar 2004 - fields: Links;    31 Mar 2004 - fields: Links;    2 Jun 2004 - fields: Champion;    1 Apr 2005 - fields: Links;    19 Sep 2005 - fields: Status, Resolution, In spec, Revisitable

Issue 5: Suspend/resume

Close with no change to the specification.
Rationale: Suspend/resume appears to be out of scope for a first release. Furthermore, it seems that suspend/resume might as well be handled by the infrastructure and therefore outside of the process model.
Links: Announcement, 25 Jun 2003     Peter Furniss, 22 Oct 2003     Tony Fletcher, 23 Oct 2003     Proposed resolution (Dieter Koenig1, 19 Jan 2004)     Peter Furniss, 26 Jan 2004
Changes: 4 Jul 2003 - fields: Document;    22 Oct 2003 - fields: Links;    23 Oct 2003 - fields: Links;    20 Jan 2004 - fields: Links;    26 Jan 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 6: Completion Condition

All of this issue is covered by its sub-issues - closed with no further change.
Links: Announcement, 25 Jun 2003     Yaron Y. Goland, 27 Aug 2004     Danny van der Rijn, 27 Aug 2004     andrew.francis@elf.mcgill.ca, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Edwin Khodabakchian, 28 Aug 2004     andrew.francis@elf.mcgill.ca, 28 Aug 2004     Satish Thatte, 31 Aug 2004     Alex Yiu, 1 Sep 2004     Ivana Trickovic, 1 Sep 2004     Axel Martens, 1 Sep 2004     Danny van der Rijn, 1 Sep 2004     Ivana Trickovic, 1 Sep 2004     Axel Martens, 1 Sep 2004     Danny van der Rijn, 1 Sep 2004     Francisco Curbera, 2 Sep 2004     Alex Yiu, 3 Sep 2004     Ivana Trickovic, 8 Sep 2004     Ivana Trickovic, 8 Sep 2004     Alex Yiu, 10 Sep 2004     Alex Yiu, 10 Sep 2004     Axel Martens, 10 Sep 2004     Axel Martens, 10 Sep 2004     Alex Yiu, 10 Sep 2004     Vinkesh Mehta, 11 Sep 2004     Ivana Trickovic, 11 Sep 2004     Ivana Trickovic, 11 Sep 2004     Vinkesh Mehta, 13 Sep 2004     Alex Yiu, 13 Sep 2004     Dieter Koenig1, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Alex Yiu, 14 Sep 2004     Alex Yiu, 14 Sep 2004     Dieter Koenig1, 14 Sep 2004     Alex Yiu, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Dieter Koenig1, 14 Sep 2004     Axel Martens, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Yaron Y. Goland, 16 Sep 2004     Danny van der Rijn, 16 Sep 2004     Proposed resolution (Satish Thatte, 17 Sep 2004)     Yaron Y. Goland, 17 Sep 2004     Danny van der Rijn, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Danny van der Rijn, 18 Sep 2004     Assaf Arkin, 18 Sep 2004     Frank Leymann, 19 Sep 2004     Satish Thatte, 19 Sep 2004     Frank Leymann, 19 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Danny van der Rijn, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 21 Sep 2004     Yaron Y. Goland, 27 Sep 2004     Danny van der Rijn, 27 Sep 2004     Assaf Arkin, 28 Sep 2004     Proposal withdrawn, conf call 8 Dec 2004     Alex Yiu, 3 Sep 2004     Alex Yiu, 8 Mar 2005     Alex Yiu, 8 Mar 2005     Ivana Trickovic, 1 Apr 2005
Changes: 4 Jul 2003 - fields: Document;    27 Aug 2004 - fields: Links;    30 Aug 2004 - fields: Links;    31 Aug 2004 - fields: Links;    1 Sep 2004 - fields: Links;    2 Sep 2004 - fields: Links;    4 Sep 2004 - fields: Links;    8 Sep 2004 - fields: Links;    10 Sep 2004 - fields: Links;    11 Sep 2004 - fields: Links;    13 Sep 2004 - fields: Links;    14 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links;    18 Sep 2004 - fields: Status, Proposed resolution, Links;    20 Sep 2004 - fields: Links;    21 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    28 Sep 2004 - fields: Links;    8 Dec 2004 - fields: Status, Links;    20 Dec 2004 - fields: Links;    8 Mar 2005 - fields: Links;    1 Apr 2005 - fields: Links;    19 Sep 2005 - fields: Status, Resolution, In spec

Issue 6.1: A low-level mechanism for completion of the flow activity

Close with no change, mark as revisitable.
Links: Announcement, 1 Apr 2005
Changes: 1 Apr 2005 - fields: Split, Title, Status, Submitter, Description, Proposed resolution, Links;    12 Sep 2005 - fields: Status, Resolution, Revisitable, In spec

Issue 6.2: A high-level mechanism for completion of the flow activity

Note: The mechanisms propsed in sub-issues 6.1 and 6.2 can coexist together and do not preclude each other.
Resolution: Proposed Ivana Trickovic, 1 Apr 2005, agreed with several amendments 14 Sept 2005

Syntax:

<flow standard-attributes>
	standard-elements
      <links>?
         <link name="ncname">+
      </links>
      <completionCondition>?
      activity+
</flow>


<completionCondition>
      <branches expressionLanguage="URI"?
		countCompletedBranchesOnly="yes|no"?>
          an-integer-expression
      </branches>?
      <booleanExpression expressionLanguage="URI"?>
          a-boolean-expression
      </booleanExpression>?
</completionCondition>

Semantics:

1. The completionCondition element is an optional element of the flow activity. Default behavior of the flow activity is that it waits for all its nested activities to complete.

2. There are two kinds of completion condition: A> <booleanExpression>: A boolean condition operating upon process variables. It is evaluated at the end of execution of each nested activity. B> <branches>: An integer value expression which is used to define condition of flavor N out of M. It is evaluated at the end of execution of each nested activity. This condition has "at least N out of M" semantics. (The exact N out of M condition semantics involve resolving racing condition among nested activities.)

3. Both conditions (<branches> and <booleanExpression>) may be specified at the same time. They will be evaluated at the end of execution of each nested activity. If at least one condition evaluates to true the <flow> activity completes successfully terminating all remaining running nested activities. If both conditions are specified, the <branches> will be evaluated first. If the boolean condition is specified the evaluation of the condition is done in a serialized fashion with respect to the nested activities directly enclosed in the flow activity.

4. If the integer value evaluated from the <branches> expression is larger than the number of nested activities in the <flow>, then bpws:invalidBranchCondition fault MUST be thrown. Note that the number of branches may be known only during runtime in some cases. Static analysis should be encouraged to detect this erroneous situation at design time when possible. (E.g. when the branches expression is a constant.)

5. <branches> expression has an optional attribute "countCompletedBranchesOnly". Its default value is "no". If countCompletedBranchesOnly is "no", it means the BPEL processor will count branches which have completed (either successfully or unsuccessfully). If countCompletedBranchesOnly is "yes", it means the BPEL processor will count branches which have completed successfully only.

6. If flow activity specifies a completionCondition element the completion condition is evaluated each time a nested activity completes. If the completion condition evaluates to true the flow activity completes successfully. All still running nested activities will be terminated.

7. Standard BPEL termination semantics applies to running nested activities when the completion condition is met. The termination of running nested activities follows the termination semantics defined in the specification (see section 13.4.4 Semantics of Activity Termination).

8. If all nested activities of the flow activity have been completed but the completion condition evaluates to false the "bpws:completionConditionFailure" MUST be thrown by the flow activity.

The following amendments to the resolution were accepted:

1. Restrict the completion condition to apply to parallel for each only.
2. the count of branches is calculated only once and won't change as the result of the parallel for each execution.
3. Fix language in section 13.4.4 Semantics of Activity Termination from:

   "However, a termination handler cannot throw any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already either faulted or is in the process of being terminated, which is what is causing the forced termination of the nested scope."

4. Add that the termination may be the outcome of early completion of parallel for each.
5. the term branches may be changed by the spec editing team to reconcile with parallel for each if they deem it appropriate.
6. "If upon completion of a directly enclosed activity, it can be determined that the completion condition can never be true the "bpws:completionConditionFailure" MUST be thrown by the parallel forEach activity."

The above was agreed (I think, prf) as part a. The amendment

Apply completion condition to both serial and parallel for each.

Issue 6.3: Partial Termination of a Scope

Changes: 31 May 2005 - fields: Split, Title, Status, Submitter, Description, Proposed resolution

Issue 6.4: Concurrency and Expression Evaluation

Close with no change

This is amendment to the proposal in Alex Yiu, 15 Sep 2005
Links: Proposed resolution (Alex Yiu, 15 Sep 2005)
Changes: 31 May 2005 - fields: Split, Title, Status, Submitter, Description, Proposed resolution;    15 Sep 2005 - fields: Links, Status, Proposed resolution;    6 Oct 2005 - fields: Status, Proposed resolution, Resolution, In spec, Revisitable

Issue 7: Import

Introduce a single <bpel:import> element used to import XSD, WSDL definitions. Zero or more <bpel:import> elements may appear as first children of the <bpel:process> element. Three required attributes must be:

• "namespace": target namespace being imported
• "location": where to find the imported information
• "importType": identifies the type of document being imported by providing the URI of the encoding language: either "http://www.w3.org/2001/XMLSchema" or "http://schemas.xmlsoap.org/wsdl/".

For example:

	<bpel:import namespace="..."  location="document-location" importType="XYZ-namespace-uri"/>

Issue 8: Non-mutability of correlation sets

Close with no change to the specification.
Rationale: The ambiguity originally perceived is no longer felt to be there. Any clarification needed will be treated as an editorial matter.
Links: Announcement, 25 Jun 2003     Discussed at meeting, 6 August (document details)     Discussed at Redmond face-to-face
Changes: 4 Jul 2003 - fields: Document;    7 Aug 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    18 Sep 2003 - fields: Links;    22 Jun 2004 - fields: Status, Proposed resolution, Resolution, Rationale, In spec

Issue 9: Static analysis

Question: Is it possible to define a conservative set of restrictions that will ensure portability?
Depends on: Inclusion of Issue 84 into the specification.
Resolution: Proposed in Alex Yiu, 13 Mar 2006, decided conf call, 15 March 2006

implementations MAY choose to perform static analysis to detect and reject process definitions that may have undefined semantics. Such analysis SHOULD be performed optimistically, that is, assuming the process has no syntactic errors then if there exists at least one execution path from each start activity in the process that can complete
Links: Announcement, 25 Jun 2003     Chris Keller, 7 Oct 2003     Eckenfels. Bernd, 7 Oct 2003     Chris Keller, 7 Oct 2003     Yaron Goland, 7 Oct 2003 (links previous 3 msgs to this issue)     Yaron Y. Goland, 9 Apr 2004     Yaron Y. Goland, 12 Aug 2004     John Evdemon, 13 Aug 2004     Yaron Y. Goland, 13 Aug 2004     John Evdemon, 16 Aug 2004     Alex Yiu, 17 Aug 2004     Yaron Y. Goland, 18 Aug 2004     Satish Thatte, 24 Aug 2004     Yaron Y. Goland, 24 Aug 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)     Assaf Arkin, 16 Sep 2004     Proposed resolution (Yaron Y. Goland, 17 Sep 2004)     Proposed resolution (Alex Yiu, 13 Mar 2006)     Danny van der Rijn, 13 Mar 2006     Alex Yiu, 13 Mar 2006     Francisco Curbera, 13 Mar 2006     Marlon Dumas, 14 Mar 2006     Alex Yiu, 15 Mar 2006     Diane Jordan, 15 Mar 2006
Changes: 4 Jul 2003 - fields: Document;    8 Oct 2003 - fields: Links;    10 Apr 2004 - fields: Links;    13 Aug 2004 - fields: Links;    14 Aug 2004 - fields: Links;    17 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Links;    24 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    17 Sep 2004 - fields: Links, Status, Proposed resolution;    13 Mar 2006 - fields: Links, Status, Proposed resolution;    14 Mar 2006 - fields: Links;    15 Mar 2006 - fields: Status, Proposed resolution, Resolution, Links;    22 Mar 2006 - fields: In spec

Issue 10: Serialization of compensation

Informally, we propose that default compensation order need only respect the control dependencies that are explicitly modeled. With the resolution of issue 1, it is far from easy to emulate strict reverse order of completion with explicit fault and compensation handlers. But with the proposed resolution of Issue 10 here, that does not matter since strict reverse order is permitted but not mandated for the default behavior. This does require an additional restriction on links to ban reentrant control paths, as described below more formally.

Definition: Control Dependency. If an activity A must complete before activity B begins, as a result of the existence of a control path from A to B in the process definition, then we say that B has a control dependency on A. Note that control dependencies may occur due to control links in <flow> as well as due to constructs like <sequence>. Control flow due to explicit "throw" is not considered a control dependency.

Part I: Consider scopes A and B such that B has a control dependency on A. Assuming both A and B completed successfully and both must be compensated as part of default compensation behavior, the compensation handler of B must run to completion before the compensation handler of A is started. This permits scopes that executed concurrently on the forward path to also be compensated concurrently in the reverse path. Of course, if one follows the strict reverse order of completion, then that necessarily respects control dependencies and is also consistent with this rule. The rule imposes a constraint on the order in which compensation handlers run during default compensation, and is not meant to be fully prescriptive about the exact order and concurrency.

Definition: Reentrant control path. Consider activities A and B enclosed in a scope S, such that B has a control dependency on A. The control path from A to B is said to be reentrant if it includes an activity C that is outside scope S, i.e., there is an activity C outside scope S such that C has a control dependency on A and B has a control dependency on C. Informally, such a reentrant path starts at A, "leaves scope S" to reach activity C and then "reenters scope S" to reach activity B. Note that reentrant control paths always involve links, at the least, one to leave the scope and one to reenter the scope.

Part II (this was NOT part of the original resolution of this issue, but was kept here for documentary completeness. It is the subject of the second resolution proposal in Satish Thatte, 8 Sep 2004): It is necessary to be able to define the default compensation behavior of a given scope independent of its peer and enclosing scopes. One reason is that such a default compensation handler may be invoked explicitly by the fault and compensation handlers of its enclosing scope. However, there are currently legal cases where the proposed resolution in Part I makes this impossible. One such example is attached. We propose to resolve this by banning reentrant control paths. This restriction would be added to the list of restrictions on links at the end of section 12.5. Clarifying note: all reentrant control paths are banned according to this proposal, whether or not they involve scope activities.

Part III: Given that compensation handlers may run concurrently with other activities including other compensation handlers, it is necessary to allow compensation handlers to use isolation scope semantics. Compensation handlers do not run within the isolation domain of their associated scopes, but fault handlers do. This creates difficulties in the isolation semantics of compensation handlers for scopes nested inside a serializable scope. Such handlers cannot use serializable scopes themselves because serializable scopes cannot be nested. However, their isolation environment is uncertain because they may be invoked from either a fault handler within the isolation domain of their enclosing scope or within the compensation handler of the same enclosing scope which is not in that isolation domain. In order to improve consistency of behavior, we propose that the compensation handler of a serializable scope will itself have serializable behavior implicitly, although it will create a separate isolation domain from that of its associated scope.

Two new issues will be raised

1. define re-entrancy fully
2. define the nature of isolation fully

Replacing part II of original resolution

I begin with a formal restatement for Part II of the resolution of Issue 10.  I will then add some explanation.

Definition: Peer-Scopes.  Two scopes S1 and S2 are said to be peer scopes if they are both directly nested within the same parent scope (including process scope).  

Definition:  Scope-controlled set.  An activity A is within the scope-controlled set of activities of scope S if either A is S itself, or A is nested within S, at any depth.

Definition:  Peer-Scope Dependency.  If S1 and S2 are peer scopes then we say that S2 has a direct peer-scope dependency on S1 if there is an activity B within the scope-controlled set of S2 and an activity A within the scope-controlled set of S1 such that B has a control dependency on A.  The peer-scope dependency relation is the transitive closure of the direct peer-scope dependency relation.

Part II:  The peer-scope dependency relation MUST NOT include cycles.  In other words, BPEL forbids a process in which there are peer scopes S1 and S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope dependency on S1.

Explanation: 

The basic motivation for Part II is to make the "respect for control dependency" rule of Part I consistent with a depth-first traversal of the scope tree for default compensation.  If we can guarantee that there is a depth-first (post-order variant) traversal consistent with Part I, we no longer have any difficulty in defining default compensation of any scope, since depth-first order implies that such compensation is only dependent on the compensation of its nested scopes.  The question then reduces to constraining control paths so we can make this guarantee.  I claim that we need only concern ourselves about control dependencies between peer scopes in the sense defined above.  An example illustrates the point. Consider the following example (taken from an earlier exchange with Alex)

<scope name="s0"> 
        <scope name="s1">
            <flow> 
                <anActivity> <source linkName="lnk1" /> </anActivity> 
                <!-- Assume that the above anActitity does not contain a 
                     scope activity -->
                <scope name="s2">
                    <target linkName="lnk1" /> 
                </scope>
            </flow>
        </scope> 
</scope> 

Does the link create a dependency between s1 and s2 that has any relevance to compensation order?  If this example is changed to

<scope name="s0"> 
        <scope name="s1">
            <flow> 
                <scope name="s7"> 
                    <source linkName="lnk1" /> 
                </scope> 
                <scope name="s2">
                    <target linkName="lnk1" /> 
                </scope>
            </flow>
        </scope> 
</scope> 

Does the situation change?  The only difference between the examples is that, whereas s1 was theoretically responsible for the compensation of the previous generic anActivity (since we assumed it does not contain a scope), it's replacement scope is an activity that is responsible for its own compensation.  But let us look further.  If we think about default compensation behavior for s1 it is going to do absolutely nothing about compensating any non-scope activities nested inside it.  Thus the fact that fact that s1 was theoretically responsible for the compensation of the generic anActivity has no consequence regarding a required ordering of compensation between s1 and s2.  Part II exploits this point and its generalization to control chains and multiply nested scopes.
Links: Announcement, 25 Jun 2003     Satish Thatte, 15 Sep 2003     Sid Askary, 9 Dec 2003     Yaron Goland, 11 Dec 2003     Satish Thatte, 12 Dec 2003     Yaron Goland, 12 Dec 2003     Assaf Arkin, 12 Dec 2003     Satish Thatte, 12 Dec 2003     Satish Thatte, 12 Dec 2003     Assaf Arkin, 12 Dec 2003     Yaron Goland, 23 Dec 2003     Ugo Corda, 23 Dec 2003     Yaron Goland, 24 Dec 2003     Ugo Corda, 24 Dec 2003     Satish Thatte, 30 Dec 2003     Ron Ten-Hove, 31 Dec 2003     Yaron Goland, 5 Jan 2004     Assaf Arkin, 7 Jan 2004     Danny van der Rijn, 7 Jan 2004     Peter Furniss, 7 Jan 2004     Satish Thatte, 7 Jan 2004     Satish Thatte, 17 Mar 2004     Reversible and Permeable Scopes v2.ppt (document details)     Satish Thatte, 16 Mar 2004     Danny van der Rijn, 16 Mar 2004     Yaron Y. Goland, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Frank Leymann, 19 Mar 2004     Discussed at Walldorf f-t-f (document details)     Satish Thatte, 18 Jun 2004     Proposed resolution (Satish Thatte, 18 Jun 2004)     Proposed resolution (Satish Thatte, 20 Jun 2004)     Issues 1 and 10.ppt (document details)     Yaron Y. Goland, 19 Aug 2004     Satish Thatte, 19 Aug 2004     Alex Yiu, 19 Aug 2004     Alex Yiu, 19 Aug 2004     Danny van der Rijn, 20 Aug 2004     Satish Thatte, 20 Aug 2004     Yaron Y. Goland, 24 Aug 2004     Satish Thatte, 24 Aug 2004     Yaron Y. Goland, 26 Aug 2004     Satish Thatte, 30 Aug 2004     Satish Thatte, 8 Sep 2004     Proposed resolution (Satish Thatte, 8 Sep 2004)     Peter Furniss, 9 Sep 2004     Dieter Koenig1, 13 Sep 2004
Changes: 4 Jul 2003 - fields: Document;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    10 Dec 2003 - fields: Links;    23 Dec 2003 - fields: Links;    7 Jan 2004 - fields: Links;    17 Mar 2004 - fields: Links;    19 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    18 Jun 2004 - fields: Links, Proposed resolution, Status;    20 Jun 2004 - fields: Links, Status, Proposed resolution;    23 Jun 2004 - fields: Links, Status, Proposed resolution, Resolution;    19 Aug 2004 - fields: Links;    22 Aug 2004 - fields: Links;    24 Aug 2004 - fields: Links;    26 Aug 2004 - fields: Links;    30 Aug 2004 - fields: Links;    8 Sep 2004 - fields: Links, Status, Proposed resolution;    9 Sep 2004 - fields: Links;    13 Sep 2004 - fields: Links;    15 Sep 2004 - fields: Status, Proposed resolution, Revised resolution;    19 Nov 2004 - fields: In spec

Issue 11: Query in <to> close should allow assigning to new locations

See Ron Ten-Hove, 25 Oct 2005 for resolution details.

As part of the resolution of this issue, issue 48 : XML Transform Support was rescinded, with a new proposal to close it.
Links: Announcement, 25 Jun 2003     Danny van der Rijn, 6 Aug 2003     Yaron Goland, 6 Aug 2003     Yaron Goland, 6 Aug 2003     Glenn Mi, 6 Aug 2003     Chris Keller, 6 Aug 2003     Edwin Khodabakchian, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Edwin Khodabakchian, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Ugo Corda, 6 Aug 2003     Chris Keller, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Chris Keller, 6 Aug 2003     Chris Keller, 6 Aug 2003     Ugo Corda, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     David RR Webber, 7 Aug 2003     Yaron Goland, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Harvey Reed, 7 Aug 2003     Yaron Goland, 8 Aug 2003     Yaron Goland, 8 Aug 2003     David RR Webber, 8 Aug 2003     Harvey Reed, 8 Aug 2003     Chris Keller, 8 Aug 2003     Danny van der Rijn, 8 Aug 2003     Yaron Goland, 8 Aug 2003     Danny van der Rijn, 8 Aug 2003     David RR Webber, 9 Aug 2003     Yaron Goland, 11 Aug 2003     David RR Webber, 12 Aug 2003     Danny van der Rijn, 12 Aug 2003     issue 48 : XML Transform Support     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Harvey Reed, 13 Aug 2003     Edwin Khodabakchian, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 18 Aug 2003     Chris Keller, 19 Aug 2003     Tony Andrews, 20 Aug 2003     Danny van der Rijn, 20 Aug 2003     Yaron Goland, 20 Aug 2003     Harvey Reed, 20 Aug 2003     Greg Ritzinger, 29 Aug 2003     Ron Ten-Hove, 29 Aug 2003     David RR Webber, 30 Aug 2003     David RR Webber, 30 Aug 2003     David RR Webber, 1 Sep 2003     Chris Keller, 2 Sep 2003     David RR Webber, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Chris Keller, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     David RR Webber, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Yaron Goland, 2 Sep 2003     Ron Ten-Hove, 2 Sep 2003     Ron Ten-Hove, 2 Sep 2003     Chris Keller, 2 Sep 2003     David RR Webber, 2 Sep 2003     David RR Webber, 3 Sep 2003     David RR Webber, 3 Sep 2003     Ron Ten-Hove, 30 Aug 2003     Ron Ten-Hove, 3 Sep 2003     David RR Webber, 3 Sep 2003     Danny van der Rijn, 3 Sep 2003     Satish Thatte, 4 Sep 2003     Chris Keller, 4 Sep 2003     Danny van der Rijn, 4 Sep 2003     Danny van der Rijn, 4 Sep 2003     Satish Thatte, 4 Sep 2003     David RR Webber, 5 Sep 2003     Chris Keller, 5 Sep 2003     Chris Keller, 5 Sep 2003     Monica Martin, 5 Sep 2003     Chris Keller, 5 Sep 2003     Monica Martin, 5 Sep 2003     Chris Keller, 5 Sep 2003     Danny van der Rijn, 5 Sep 2003     David RR Webber, 5 Sep 2003     David RR Webber, 5 Sep 2003     David RR Webber, 5 Sep 2003     Ugo Corda, 5 Sep 2003     Danny van der Rijn, 5 Sep 2003     Discussed at Redmond face-to-face     Danny van der Rijn, 3 Feb 2004     Edwin Khodabakchian, 3 Feb 2004     Pal Takacsi-Nagy, 3 Feb 2004     Edwin Khodabakchian, 3 Feb 2004     David RR Webber, 3 Feb 2004     Satish Thatte, 4 Feb 2004     Steve Capell, 4 Feb 2004     Alastair J. Green, 4 Feb 2004     David RR Webber, 4 Feb 2004     Peter Furniss, 4 Feb 2004     David RR Webber, 4 Feb 2004     Kristofer Agren, 5 Feb 2004     Danny van der Rijn, 13 Feb 2004     Monica J. Martin, 15 Feb 2004     David RR Webber, 15 Feb 2004     Diane Jordan, 16 Feb 2004     Diane Jordan, 16 Feb 2004     discussion and straw-poll, 18 Feb 2004 call     Danny van der Rijn, 18 Feb 2004     Danny van der Rijn, 18 Feb 2004     Glenn Mi, 19 Feb 2004     Danny van der Rijn, 19 Feb 2004     Danny van der Rijn, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     David RR Webber, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     David RR Webber, 23 Feb 2004     Kristofer Agren, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     Edwin Khodabakchian, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     Kristofer Agren, 23 Feb 2004     Alex Yiu, 23 Feb 2004     Danny van der Rijn, 24 Feb 2004     Alex Yiu, 24 Feb 2004     Alex Yiu, 26 Feb 2004     Yaron Y. Goland, 26 Feb 2004     David RR Webber, 26 Feb 2004     Edwin Khodabakchian, 26 Feb 2004     Monica J. Martin, 26 Feb 2004     Ron Ten-Hove, 26 Feb 2004     David RR Webber, 26 Feb 2004     Glenn Mi, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Glenn Mi, 27 Feb 2004     Chris Keller, 27 Feb 2004     Yaron Y. Goland, 27 Feb 2004     Ron Ten-Hove, 27 Feb 2004     David RR Webber, 27 Feb 2004     David RR Webber, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Chris Keller, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Chris Keller, 27 Feb 2004     Alex Yiu, 28 Feb 2004     Monica J. Martin, 28 Feb 2004     Yaron Y. Goland, 1 Mar 2004     Alex Yiu, 2 Mar 2004     Danny van der Rijn, 2 Mar 2004     David RR Webber, 2 Mar 2004     Alex Yiu, 2 Mar 2004     Danny van der Rijn, 2 Mar 2004     Yaron Y. Goland, 2 Mar 2004     Edwin Khodabakchian, 3 Mar 2004     Alex Yiu, 3 Mar 2004     Ugo Corda, 3 Mar 2004     Alex Yiu, 3 Mar 2004     Kristofer Agren, 3 Mar 2004     David RR Webber, 3 Mar 2004     Ron Ten-Hove, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     David RR Webber, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     David RR Webber, 3 Mar 2004     David RR Webber, 16 Mar 2004     Danny van der Rijn, 25 Mar 2004     David RR Webber, 26 Mar 2004     Discussed at Walldorf f-t-f (document details)     discuessed on 28 April call (document details)     Peter Furniss, 5 May 2004     see rationale in issue 100     Proposed resolution (Alex Yiu, 4 Jan 2005)     Proposed resolution (Ugo Corda, 31 Mar 2005)     Yaron Y. Goland, 31 Mar 2005     Ugo Corda, 31 Mar 2005     Satish Thatte, 4 Apr 2005     Ugo Corda, 4 Apr 2005     Satish Thatte, 4 Apr 2005     Ugo Corda, 4 Apr 2005     Yaron Y. Goland, 5 Apr 2005     Yaron Y. Goland, 5 Apr 2005     Ugo Corda, 5 Apr 2005     Ugo Corda, 5 Apr 2005     Yaron Y. Goland, 7 Apr 2005     Yaron Y. Goland, 7 Apr 2005     Ugo Corda, 7 Apr 2005     Ugo Corda, 7 Apr 2005     Yaron Y. Goland, 8 Apr 2005     Ugo Corda, 8 Apr 2005     Yaron Y. Goland, 11 Apr 2005     Satish Thatte, 26 Apr 2005     Ugo Corda, 26 Apr 2005     Satish Thatte, 26 Apr 2005     Ugo Corda, 27 Apr 2005     Francisco Curbera, 27 Apr 2005     Eckenfels. Bernd, 27 Apr 2005     Proposed resolution (Chris Keller, 28 Apr 2005)     Satish Thatte, 30 Apr 2005     Francisco Curbera, 2 May 2005     Yaron Y. Goland, 2 May 2005     Alex Yiu, 2 May 2005     Chris Keller, 2 May 2005     Alex Yiu, 2 May 2005     Chris Keller, 2 May 2005     Alex Yiu, 2 May 2005     Chris Keller, 2 May 2005     Alex Yiu, 2 May 2005     Yaron Y. Goland, 3 May 2005     Yaron Y. Goland, 3 May 2005     Eckenfels. Bernd, 3 May 2005     Eckenfels. Bernd, 3 May 2005     Ugo Corda, 3 May 2005     Chris Keller, 4 May 2005     Chris Keller, 4 May 2005     Alex Yiu, 10 May 2005     Danny van der Rijn, 10 May 2005     Chris Keller, 10 May 2005     Alex Yiu, 10 May 2005     Chris Keller, 10 May 2005     Francisco Curbera, 10 May 2005     Alex Yiu, 10 May 2005     Yaron Y. Goland, 10 May 2005     Alex Yiu, 10 May 2005     Francisco Curbera, 11 May 2005     Satish Thatte, 16 May 2005     Eckenfels. Bernd, 17 May 2005     Diane Jordan, 3 Oct 2005     Ron Ten-Hove, 5 Oct 2005     Chris Keller, 5 Oct 2005     Proposed resolution (Ron Ten-Hove, 11 Oct 2005)     Alexandre Alves, 12 Oct 2005     Alex Yiu, 12 Oct 2005     Ron Ten-Hove, 12 Oct 2005     Alexandre Alves, 12 Oct 2005     Ron Ten-Hove, 12 Oct 2005     Proposed resolution (Ron Ten-Hove, 12 Oct 2005)     Alexandre Alves, 15 Oct 2005     Ron Ten-Hove, 17 Oct 2005     Chris Keller, 17 Oct 2005     Ron Ten-Hove, 17 Oct 2005     Proposal rescinds issue 47     Proposed resolution (Ron Ten-Hove, 18 Oct 2005)     Alex Yiu, 18 Oct 2005     Chris Keller, 18 Oct 2005     Ron Ten-Hove, 18 Oct 2005     Alexandre Alves, 18 Oct 2005     Danny van der Rijn, 18 Oct 2005     Chris Keller, 18 Oct 2005     Ron Ten-Hove, 18 Oct 2005     Ron Ten-Hove, 18 Oct 2005     Ron Ten-Hove, 18 Oct 2005     Alex Yiu, 18 Oct 2005     Chris Keller, 18 Oct 2005     Alex Yiu, 19 Oct 2005     Ron Ten-Hove, 19 Oct 2005     Proposed resolution (Ron Ten-Hove, 19 Oct 2005)     Ron Ten-Hove, 19 Oct 2005     Proposed resolution (Ron Ten-Hove, 19 Oct 2005)     Proposed resolution (Dieter Koenig1, 19 Oct 2005)     Proposed resolution (Ron Ten-Hove, 19 Oct 2005)     Satish Thatte, 23 Oct 2005     Ron Ten-Hove, 24 Oct 2005     Ron Ten-Hove, 24 Oct 2005     Satish Thatte, 24 Oct 2005     Proposed resolution (Ron Ten-Hove, 25 Oct 2005)     Danny van der Rijn, 25 Oct 2005     Ron Ten-Hove, 25 Oct 2005     Alex Yiu, 25 Oct 2005     Chris Keller, 25 Oct 2005     Alexandre Alves, 26 Oct 2005     Ron Ten-Hove, 26 Oct 2005     Alexandre Alves, 26 Oct 2005     Diane Jordan, 7 Nov 2005
Changes: 4 Jul 2003 - fields: Document;    7 Aug 2003 - fields: Links, Champion;    8 Aug 2003 - fields: Links;    9 Aug 2003 - fields: Links;    12 Aug 2003 - fields: Links;    13 Aug 2003 - fields: Links;    14 Aug 2003 - fields: Links;    19 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Links, Proposed resolution;    29 Aug 2003 - fields: Links;    30 Aug 2003 - fields: Links;    3 Sep 2003 - fields: Links;    4 Sep 2003 - fields: Links;    8 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    3 Feb 2004 - fields: Links;    4 Feb 2004 - fields: Links;    5 Feb 2004 - fields: Links;    16 Feb 2004 - fields: Links;    18 Feb 2004 - fields: Links;    19 Feb 2004 - fields: Links;    25 Feb 2004 - fields: Links;    26 Feb 2004 - fields: Links;    27 Feb 2004 - fields: Links;    28 Feb 2004 - fields: Links;    1 Mar 2004 - fields: Links;    3 Mar 2004 - fields: Links;    4 Mar 2004 - fields: Links;    16 Mar 2004 - fields: Links;    26 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution;    5 May 2004 - fields: Status, Resolution, Links;    6 May 2004 - fields: Links;    23 Jun 2004 - fields: Links;    13 Sep 2004 - fields: Categories;    5 Jan 2005 - fields: Links, Status, Proposed resolution;    10 Jan 2005 - fields: Links, Status, Proposed resolution;    1 Apr 2005 - fields: Links, Status, Proposed resolution;    4 Apr 2005 - fields: Links;    5 Apr 2005 - fields: Links;    7 Apr 2005 - fields: Links;    11 Apr 2005 - fields: Links;    27 Apr 2005 - fields: Links;    29 Apr 2005 - fields: Links, Status, Proposed resolution;    1 May 2005 - fields: Links;    2 May 2005 - fields: Links;    3 May 2005 - fields: Links;    4 May 2005 - fields: Links;    10 May 2005 - fields: Links;    11 May 2005 - fields: Links;    16 May 2005 - fields: Links;    18 May 2005 - fields: Links;    4 Oct 2005 - fields: Links;    5 Oct 2005 - fields: Proposed resolution, Links;    12 Oct 2005 - fields: Links, Status, Proposed resolution;    13 Oct 2005 - fields: Links, Status, Proposed resolution;    17 Oct 2005 - fields: Links;    19 Oct 2005 - fields: Links, Status, Proposed resolution;    20 Oct 2005 - fields: Links, Status, Proposed resolution;    24 Oct 2005 - fields: Links;    25 Oct 2005 - fields: Links;    26 Oct 2005 - fields: Links, Status, Proposed resolution;    9 Nov 2005 - fields: Links, Status, Proposed resolution, Resolution;    22 Feb 2006 - fields: In spec

Issue 11.1: Making <assign> truly extensible

After have a discussion and straw-poll at the Hawthorne NY F2F, I believe that the timing is now appropriate for me to formally to open a new issue (sub issue) 11.1 to make <assign> truely extensible.

Proposed Solution:

In order to have the true spirit of extensibility of <assign> syntax, we would like to suggest the following syntax changes:

The <assign> construct contains one or more elementary data manipulation operations, which are <copy> or operations defined as extension under other namespaces.

<assign standard-attributes>
    standard-elements
    (
      <copy>
        from-spec
        to-spec
      </copy>   |
      any-element-of-other-namespace
    )+
</assign>

The <copy> operation copies a type-compatible value from the source ("from-spec") to the destination ("to-spec").

[Note: the above changes go into section 9.4, starting from second paragraph]

Related Schema Change: From:

-------------------------------------
    <complexType name="tAssign">
        <complexContent>
            <extension base="bpws:tActivity">
                <sequence>
                    <element name="copy" type="bpws:tCopy"
                             maxOccurs="unbounded"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
-------------------------------------
To: 
-------------------------------------
    <complexType name="tAssign"> 
        <complexContent> 
            <extension base="bpws:tActivity"> 
                <sequence minOccurs="0"> 
                    <element name="copy" type="bpws:tCopy" /> 
                    <choice minOccurs="0" maxOccurs="unbounded"> 
                        <element name="copy" type="bpws:tCopy" /> 
                        <any namespace="##other"
                             processContents="lax"/> 
                    </choice> 
                </sequence> 
            </extension> 
        </complexContent> 
    </complexType>
-------------------------------------

[Note: the XSD changes is not that straightforward because we want to avoid the non-deterministic choice content model problem due to XSD semantics and our current usage of its extension mechansim (tActivity). Also, due to similar restrictions from XSD, the constraint of at least one data manipulation operation cannot be enforced directly by the XSD itself. BPEL implementation needs to do its own validation post XSD validation, similar to the case of enforcing that only one of multiple optional attributes at <variable> declaration is used.]

Background:

Currently, <assign> is an BPEL extensible activity element. That means people can potentially add some other construct under <assign> to denote some of operations that the spec do not define. (So, the other operations can be still under the same atomic assignment unit.)

However, the BPEL syntax grammar (including its XMLSchema) requires at least one <copy> under <assign>. That is:

<assign standard-attributes>
    standard-elements
    <copy>+
       from-spec
        to-spec
    </copy>
</assign>

<assign>
    <foo:barOperation ... /> 
</assign>

Due to the current usage of XML Schema definition, it also forces the extension element must appear before the <copy> element. E.g.: the following usage is disallowed by the current schema design:

<assign>
    <copy> ... </copy>
    <foo:barOperation ... /> 
</assign>

Proposed resolution: Alex Yiu, 14 Jan 2005
Links: Proposed resolution (Alex Yiu, 4 Jan 2005)     Proposed resolution (Alex Yiu, 14 Jan 2005)
Changes: 5 Jan 2005 - new sub-issue;    14 Jan 2005 - fields: Links, Status, Proposed resolution;    20 May 2005 - fields: In spec;    12 Sep 2005 - fields: In spec

Issue 12: XML types and WS Interactions

Issue 12 should be closed with no (further) change to the spec.

Rationale: Issue 12 was split at the December f-t-f into 12.1 and 12.2, both of which were then closed. The original proposed resolution of 12 was made into 12.1, with 12.2 as a distinct sub-issue. (In other similar cases, we have followed a pattern where the main issue is closed, with only one numbered sub-issue)
Links: Announcement, 25 Jun 2003     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Yaron Y. Goland, 10 Dec 2004)     Ron Ten-Hove, 10 Dec 2004     Proposed resolution (Peter Furniss, 29 Apr 2005)
Changes: 4 Jul 2003 - fields: Document;    22 Apr 2004 - fields: Links;    11 Dec 2004 - fields: Links, Status, Proposed resolution;    14 Dec 2004 - fields: Links;    29 Apr 2005 - fields: Links, Status, Proposed resolution;    19 May 2005 - fields: Status, Proposed resolution, Resolution, In spec

Issue 12.1: XML types and WS Interactions (Part of)

Allow messaging activities involving messageTypes with a single part defined using an element (e.g. a WS-I doc/lit) to submit a BPEL variable of the same element type as the part directly to the message activity rather than having to submit a BPEL messageType variable.

Rationale: Today all message activities in BPEL require the use of a WSDL messageType variable. But moving forward it is expected that WS-I’s doc/lit design pattern will be a common Web Services design pattern. This pattern requires that a message have exactly one part and that the part be defined using an element. In other words messages having to look something like:

<xsd:element name="myElem">
     <xsd:complexType>
        <xsd:sequence>
           <xsd:element name="xsdtns:detail" ... />
        </xsd:sequence>
     </xsd:complexType>
</xsd:element>
...
<wsdl:message name="myMsgType">
     <wsdl:part name="myPartName" element="xsdtns:myElem" />
</wsdl:message>

Rather than requiring users to wrap the single element of content into a messageType variable it would be much simpler to allow, in these cases, for the user to directly submit an element BPEL variable to the message operation. The consequence is that a BPEL which only deals with WS-I compliant doc/lit operations would never need to use messageType variables at all. They could just use element variables.

Allowing this optimization, besides making BPEL code simpler, would also put BPEL in very good shape for the eventual transition to WSDL 2.0. WSDL 2.0 messages do not have any parts at all and are defined exclusively using XML elements. So by allowing for message activities that interact with WSDL 1.1 messages with a single element-based part to avoid using messageType variables and just use XML variables we make it much easier for BPEL 2.0 code to make the transition to a WSDL 2.0 world.

Changes Required: This proposal depends on issue 93 and 145. In the case where a messageType consists of a single part defined using an element it will be legal to submit a BPEL element variable instead of a messageType variable to messaging activities. The onEvent handler will be extended to have an element attribute in addition to a messageType attribute. The catch semantics are extended so that if there is no messageType based catch that matches a fault whose data is a messageType then if the messageType has one part defined using an element then a matching element based catch can grab it.

Section 11.3

Add to the end of the section: If the WSDL operation used to send and/or receive a message in an invoke activity is defined as a message containing exactly one part which itself is defined using an element then a BPEL variable of the same element type as used to define the part MAY be submitted directly to the invoke activity. The result of submitting a BPEL variable in the previously defined circumstance MUST be the equivalent of declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. In the case of an inputVariable the value of the submitted BPEL variable will be used to set the value of the part in the anonymous temporary WSDL message variable. In the case of an outputVariable the value of the received part in the temporary WSDL message variable will be used to set the value of the submitted BPEL variable.

Section 11.4

Insert after the paragraph that begins “It is permissible to have the createInstance attribute”: If the WSDL operation used to receive or send a message in a request/reply activity is defined as a message containing exactly one part which itself is defined using an element then a BPEL variable of the same element type as used to define the part MAY be submitted directly to the request/reply activity. The result of submitting a BPEL variable in the previously defined circumstance MUST be the equivalent of declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. In the case of a receive activity, the incoming part’s value will be used to set the value of the submitted BPEL variable. In the case of a reply activity the value of the submitted BPEL variable will be used to set the value of the part in the anonymous temporary WSDL message variable that is sent out. In the case of a reply that is sending a fault the same logic applies but using a fault name rather than an operation name.

Section 12.4

Change: Each pick activity MUST include at least one onMessage event. The semantics of the onMessage event is identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, and the constraint regarding simultaneous enablement of conflicting receive actions.

To: Each pick activity MUST include at least one onMessage event. The semantics of the onMessage event is identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, the single element-based part message short cut and the constraint regarding simultaneous enablement of conflicting receive actions.

Section 13.4

Change: A fault response to an invoke activity is one source of faults, with obvious name and data aspects based on the definition of the fault in the WSDL operation.

To: A fault response to an invoke activity is one source of faults, with name and data aspects based on the definition of the fault in the WSDL operation.

Change: Because of the flexibility allowed in expressing the faults that a catch activity can handle, it is possible for a fault to match more than one fault handler. The following rules are used to select the catch activity that will process a fault: • If the fault has no associated fault data, a catch activity that specifies a matching faultName value and no faultVariable attribute will be selected if present. Otherwise, the default catchAll handler is selected if present. • If the fault has associated fault data, a catch activity specifying a matching faultName value and a faultVariable whose type (WSDL message type) matches the type of the fault’s data will be selected if present. Otherwise, a catch activity with no specified faultName and with a faultVariable whose type matches the type of the fault data will be selected if present. Otherwise, the default catchAll handler is selected if present. If no catch or catchall is selected, the fault is not caught by the current scope and is rethrown to the immediately enclosing scope (see Implicit Fault and Compensation Handlers for a more complete description of the default fault and compensation handling behavior). If the fault occurs in (or is rethrown to) the global process scope, and there is no matching fault handler for the fault at the global level, the process terminates abnormally, as though an exit activity had been performed.

To: Because of the flexibility allowed in expressing the faults that a catch activity can handle, it is possible for a fault to match more than one fault handler.

In the case of faults thrown without associated data the fault will be caught as follows:

• If there is a catch activity with a matching faultName value that does not specify a faultVariable attribute then the fault is passed to the identified catch activity.
• Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler.
• Otherwise the fault is thrown to the immediately enclosing scope.

• If there is a catch activity with a matching faultName value that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified catch activity.
• Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity with a matching faultName value that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element.
• Otherwise if there is a catch activity without a faultName attribute that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified catch activity.
• Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity without a faultName attribute that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element.
• Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler.
• Otherwise the fault is thrown to the immediately enclosing scope.

If the fault occurs in (or is rethrown to) the global process scope, and there is no matching fault handler for the fault at the global level, the process terminates abnormally, as though an exit activity had been performed. See Implicit Fault and Compensation Handlers for a more complete description of the default fault and compensation handling behavior.

Section 13.5

Change the onEvent element definition to make messageType optional and add an optional element attribute.

      <onEvent partnerLink="ncname" portType="qname"?
           operation="ncname" variable="ncname"?
           (messageType="qname" | element="qname" )? >

Section 13.5.1

Change: The messageType attribute specifies the type of the variable by referencing a message type definition using its QName. The type of the variable (as specified by the messageType attribute) must be the same as the type of the input message defined by operation referenced by the operation attribute. The variable and messageType attributes constitute the declaration of a variable of that name and type within an implicit scope associated with the event handler.

To: The messageType attribute specifies the type of the variable by referencing a message type definition using its QName. The type of the variable (as specified by the messageType attribute) must be the same as the type of the input message defined by operation referenced by the operation attribute. Optionally the messageType attribute may be omitted and instead the element attribute substituted if the message to be received has a single part and that part is defined with an element type that matches the element type referenced by the element attribute. The variable and messageType/element attribute constitute the declaration of a variable of that name and type within an implicit scope associated with the event handler. If an element attribute is used then the binding of the incoming message to the variable declared in the onEvent handler occurs as specified for the receive activity in section 11.4.
Links: Proposed resolution (Yaron Y. Goland, 10 Dec 2004)
Changes: 14 Apr 2005 - fields: In spec;    29 Apr 2005 - fields: Resolution

Issue 12.2: Accessing messageType properties under issue 12

Submitter's proposal: Close with no change.
Resolution: Proposed in Yaron Y. Goland, 4 Mar 2005, decided conf call 23 March 2005

Close with no action
Rationale: Properties will be introduced into WSDL with BPEL. Which means that everyone using properties will know about BPEL and BPEL's focus on using single element variables rather than WSDL message variables for WS-I doc/lit messages. I therefore find it difficult to believe that a bunch of people will go out and write properties on WS-I doc/lit messages rather than putting those properties directly on the underlying elements. Yes, there are some situations where, in theory, the same element could be used on two different messages and so need two different sets of properties. But this would be very strange for a WS-I doc/lit scenario. In WS-I doc/lit the element is the message. So elements tend to be unique to particular messages. If two messages need different sets of properties then they're equally likely to be using two different parent elements. From what I can see, this issue represents a problem that probably doesn't exist.
Links: Announcement, 18 Jan 2005     Proposed resolution (Yaron Y. Goland, 4 Mar 2005)
Changes: 7 Jan 2005 - new sub-issue;    4 Mar 2005 - fields: Links, Status, Proposed resolution

Issue 13: Future Usage of XPATH 2.0 and XQuery 1.0

A. Should we adjust the BPEL syntax (element rather than attribute content for XQuery) to prepare for the use of XQuery in future?

B. Should we change the mandatory dependency for query and expression support from XPATH 1.0 to XPATH 2.0? Keeping in mind that XPATH 1.0 is very widely deployed whereas XPATH 2.0 is not yet a recommendation, although it is likely to become one in roughly the same timeframe as the final release of the specification produced by the WSBPEL TC.
Resolution: Proposed in rkhalaf, 10 Dec 2003, decided at conf call, 21 January 2004

The proposal is to replace things with expressions and queries from being an attribute to being an element. This would affect <from>, <to> , <propertyAlias>, and conditions. This would gear up for using other languages for querying that may have a structured syntax. An example is the upcoming XQueryX, a proposal for XQuery using XML syntax. The case for string queries is also shown below.

With elements instead of attributes, we can allow one to override the default query/expression languages locally. The proposal allows for optional query/expressionLanguage attributes on queries and conditions that can locally override the global default.

Current syntax:

<wsbp:from variable="ncname" part="ncname"? query="queryString"?/>


<wsbp:link ... transitionCondition="..." />
<wsbp:targets joinCondition="...">
.. the same for switch's case, and the whileCondition

Proposed syntax

<wsbp:from variable="ncname" part="ncname"?>
  <wsbp:query queryLanguage=".."?> ?      query goes here
  </wsbp:query>
</wsbp:from>

<wsbp:from variable="ncname" part="ncname"?>
  <wsbp:query>
  /shipNotice/ShipNoticeHeader/shipOrderID
  </wsbp:query>
</wsbp:from>

<wsbp:source ... >
      <wsbp:transitionCondition 
expressionLanguage=".."?>...</transitionCondition>?
</wsbp:source>

<wsbp:targets>
    <wsbp:joinCondition expressionLanguage="..."?>...</joinCondition> ?
     <wsbp:link.... />
</wsbp:targets>

Issue 14: Restriction on join conditions

Close with no change to the specification.
Rationale: The referenced paper discusses different behavior (called side effects) for processes run with or without DPE. From looking at the paper, it seems that running processes without DPE introduces new situations where the process just stops and never reaches the end.
Links: Announcement, 25 Jun 2003     Proposed resolution (Dieter Koenig1, 19 Jan 2004)     Peter Furniss, 26 Jan 2004
Changes: 4 Jul 2003 - fields: Document;    20 Jan 2004 - fields: Links;    26 Jan 2004 - fields: Links, Status, Proposed resolution;    4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 15: WSDL MEPs

Whatever action we were going to take with respect to WSDL 2.0 has been taken and therefore this issue can be closed with 'no change'.
Links: Announcement, 25 Jun 2003     Kevin Liu, 22 Sep 2003     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 4 Jul 2003 - fields: Document;    10 Sep 2003 - fields: Champion;    23 Sep 2003 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    6 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec

Issue 16: Ensuring exactly once

On step 6, how can we prevent process A from executing the invoke a second time, creating another instance of process B, and debiting the account a second time?
Resolution: proposed in Mike Marin, 10 Dec 2003, agreed at Melbourne face-to-face, 10 December 2003

Closed without change to the specification.

Vote 18 for, 6 against, 5 abstain
Links: Mike Marin, 22 May 2003     Fred A Cummins, 22 May 2003     Mike Marin, 22 May 2003     Mark Little, 23 May 2003     Mike Marin, 23 May 2003     David RR Webber, 24 May 2003     Satish Thatte, 24 May 2003     Mark Little, 24 May 2003     Maciej Szefler, 26 May 2003     Mark Little, 27 May 2003     Maciej Szefler, 27 May 2003     Announcement, 25 Jun 2003     proposed resolution (Mike Marin, 10 Dec 2003)
Changes: 4 Jul 2003 - fields: Document, Links;    10 Dec 2003 - fields: Status, Resolution, Links

Issue 17: Asynchronous operations

Close with no change to the specification.
Links: Mike Marin, 22 May 2003     Assaf Arkin, 27 May 2003     Maciej Szefler, 27 May 2003     Mark Little, 27 May 2003     Edwin Khodabakchian, 27 May 2003     Maciej Szefler, 27 May 2003     Edwin Khodabakchian, 27 May 2003     Maciej Szefler, 28 May 2003     Assaf Arkin, 30 May 2003     Maciej Szefler, 30 May 2003     Satish Thatte, 2 Jun 2003     Assaf Arkin, 2 Jun 2003     Announcement, 25 Jun 2003     Proposed resolution (Yaron Goland, 20 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;    21 Jan 2004 - fields: Links, Status, Proposed resolution;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution

Issue 18: BPEL Visual Binding

The problem is that this means that exporting a BPEL definition from one BPEL Design Time for input into another will result in a BPEL definition that will not be easily editable as all the graphical information would be lost.

In the extreme, for a complex design, it could mean that designer of business processes using BPEL is effectively locked into the BPEL Design Time software provider that they initially choose. This I don't think is a good idea.

THE SOLUTION ?

To solve this problem I would like to suggest the setting up of a sub-committe of the TC that has responsibilty for developing a "BPEL Visual Binding" specification which would contain the relevant visual information from the BPEL Design Time. The idea would be that the Visual Binding specification is a separate document to the main BPEL specification. Also BPEL Design Time Implementations could export either:
1. The BPEL XML Definition alone, or
2. The BPEL XML Definition PLUS the BPEL Visual Binding

The former could be used for input to a BPEL Run Time and the latter could be input into some other BPEL Design Time.

By creating a separate, but related, specification, it should be possible to carry out the work on the BPEL Visual Binding specifcation in parallel, without hindering any work on the main BPEL specification.
Resolution: Proposed in Satish Thatte, 23 Jan 2004, decided 4 February 2004 con call

Close with no change to the specification.
Rationale: Visual notation is a separable dimension and arguably out of scope for this TC.

David Burdett originally opened the issue.

Discussion:

David wrote that he was agreeable to closing this, but added the suggestion that the TC make a non-binding recommendation to implementers of BPEL to provide an export file and related specification that provided information about any graphical representations of a BPEL definition. So that others could provide import facilities if they wanted to.

My response to that suggestion was that making such a recommendation will start the whole discussion about whether BPEL is meant to be directly used for design or compiled out of some higher level design metaphor. I would much prefer to avoid a discussion that would be tool specific anyway.

I suggested to David that he open a separate issue for the non-binding recommendation if he felt that was important to have.
Links: David Burdett, 22 May 2003     Tony Andrews, 22 May 2003     David Burdett, 22 May 2003     Rajesh Pradhan, 22 May 2003     David Burdett, 23 May 2003     David RR Webber, 23 May 2003     Jim Webber, 23 May 2003     Stephen White, 23 May 2003     Edwin Khodabakchian, 23 May 2003     Waqar Sadiq, 23 May 2003     David Burdett, 23 May 2003     Waqar Sadiq, 23 May 2003     Edwin Khodabakchian, 23 May 2003     Stephen White, 23 May 2003     Maciej Szefler, 26 May 2003     David RR Webber, 27 May 2003     Rajesh Pradhan, 27 May 2003     David Burdett, 27 May 2003     Jim Webber, 27 May 2003     Waqar Sadiq, 27 May 2003     David RR Webber, 27 May 2003     Maciej Szefler, 27 May 2003     Fred A Cummins, 27 May 2003     Assaf Arkin, 27 May 2003     David RR Webber, 27 May 2003     David Burdett, 28 May 2003     David Burdett, 28 May 2003     J. Matthew Pryor, 28 May 2003     David RR Webber, 28 May 2003     David RR Webber, 29 May 2003     Assaf Arkin, 30 May 2003     Announcement, 25 Jun 2003     Satish Thatte, 23 Jan 2004     Proposed resolution (Satish Thatte, 23 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;    23 Jan 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 19: Multiple properties associated to a single property alias

In practice, it is likely that some number of processes will refer to the same properties, but that these BPEL files may not be aware of one another. Thus, it would be good to explore the ability to associate multiple properties with a single property alias.

Part of this work may involve determining how to map different type specifications (which may be (probably must be) structurally "similar", but named differently) that are associated with the property definition.

This is probably a lower-level issue, not required to be addressed early on. However, we should consider it for usability purposes.
Resolution: Proposed in Satish Thatte, 21 Jan 2004, decided 4 February 2004 con call

Close with no change to the specification.
Rationale: While generalization of type systems may be useful in some circumstances, we have stayed with XML types in BPEL for a good reason -interoperability. On the issue of property sharing, the existing mechanisms already allow the same alias to be used for many properties, so no change seems to be required there. Fred Carter originally opened the issue and he agreed with me in e-mail that the issue should be closed with no changes to the spec.
Links: Announcement, 25 Jun 2003     Proposed resolution (Satish Thatte, 21 Jan 2004)
Changes: 4 Jul 2003 - fields: Document;    21 Jan 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 20: installing compensation handlers for faulted scopes

currently, i beleive, a compensation handler is not installed for a faulted scope, irrespective of whether the fault is propagated-up or not.

i realize, as Satish pointed to, there are issues with allowing the fault handler to attempt alternative normal completion.

however, i would like to discuss this further to help convince ourselves that we are embarked on the right model for fault/compensation handling.

(a) Normally, if a fault handler were to be able to handle the fault itself, that is, do corrective actions (both undo and redo), then the fault is not rethrown, and the forward action can proceed as normally intended.

(b) On the other hand, if the fault handler is not able to handle the fault, perhaps it failed somewhere in its attempt to undo/redo, it rethrows the fault, and the normal execution is short-circuited.

in the case of (a), it seems reasonable to install a compensation handler, since the fault was successfully handled, and forward progress can be made. If this is not the case, the problem is that every forward action has to check if the previous action(s) had successfully completed, which is non-trivial. In such a case, the developer is most-likely going to almost *always* rethrow* a fault in order to avoid having to check for every action if the previous one(s) had successfully completed.

in the case of (b), it seems reasonable to *not* install a compensation handler, since the fault was not successfully handled, or rather the action did not completed successfully.

summary: the fact whether a fault was rethrown by a fault handler may be used to decide whether to install a compensation handler or not. thanks.
Resolution: Proposed in message Ram Jeyaraman, 29 Sep 2003, decided in TC conf call, 1 October 2003

Closed with no further action

Links: Ram Jeyaraman, 28 May 2003     Assaf Arkin, 30 May 2003     Ram Jeyaraman, 31 May 2003     Assaf Arkin, 31 May 2003     Ram Jeyaraman, 31 May 2003     Assaf Arkin, 2 Jun 2003     David RR Webber, 2 Jun 2003     Assaf Arkin, 3 Jun 2003     David RR Webber, 3 Jun 2003     Announcement, 25 Jun 2003     Satish Thatte, 15 Sep 2003     Discussed at Redmond face-to-face     Ram Jeyaraman, 22 Sep 2003     Satish Thatte, 23 Sep 2003     Ram Jeyaraman, 24 Sep 2003     Proposed resolution (Ram Jeyaraman, 29 Sep 2003)     Ram Jeyaraman, 30 Sep 2003     Monica Martin, 30 Sep 2003
Changes: 4 Jul 2003 - fields: Document, Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    22 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    24 Sep 2003 - fields: Links;    30 Sep 2003 - fields: Links, Proposed resolution, Status;    1 Oct 2003 - fields: Vote announcement, Links, Status, Resolution, Proposed resolution

Issue 21: faultHandlers to be renamed cancellationHandlers

Closed with no further action.
Rationale:

The existing text below is considered clear enough:

The completion of the activity of a fault handler, even when it does not rethrow the fault handled, is never considered successful completion of the attached scope and compensation is never enabled for a scope that has had an associated fault handler invoked.

Issue 22: Implicit <sequence> macro

  <scope>
   <receive/>
   <invoke/>
   <reply/>
  </scope>

  <scope>
   <sequence>     <!-- implicit sequence -->
    <receive/>
    <invoke/>
    <reply/>
   </sequence>
  </scope>

Close with no change to the specification.
Rationale: The issue was originally opened by Yuzo Fujishima. There was a discussion thread on the proposal and it was agreed that the potential complexity of the optimization outweighted its benefit. The thread concluded with a general agreement to close the issue but no actual proposal was made. I (Yaron) exchanged e-mail with Yuzo in which he confirmed that he agreed that the issue should be closed with no change to the spec.
Links: Yuzo Fujishima, 11 Jun 2003     Satish Thatte, 12 Jun 2003     Edwin Khodabakchian, 12 Jun 2003     Frank Leymann, 12 Jun 2003     Satish Thatte, 12 Jun 2003     Assaf Arkin, 12 Jun 2003     Greg Ritzinger, 12 Jun 2003     Waqar Sadiq, 12 Jun 2003     David RR Webber, 12 Jun 2003     Prasad Yendluri, 12 Jun 2003     Ugo Corda, 12 Jun 2003     Satish Thatte, 12 Jun 2003     Neelakantan Kartha, 12 Jun 2003     Assaf Arkin, 12 Jun 2003     Ugo Corda, 12 Jun 2003     Assaf Arkin, 12 Jun 2003     Ugo Corda, 12 Jun 2003     Prasad Yendluri, 12 Jun 2003     Ron Ten-Hove, 12 Jun 2003     Glenn Mi, 13 Jun 2003     Assaf Arkin, 13 Jun 2003     Announcement, 25 Jun 2003     Proposed resolution (Yaron Goland, 19 Jan 2004)
Changes: 4 Jul 2003 - fields: Document, Links;    31 Jul 2003 - fields: Champion;    20 Jan 2004 - fields: Links, Status, Proposed resolution;    4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 23: Rationale for sequence vs. flow

This may be possibly confusing for the readers (wondering if they missed anything). So the redundancy needs to be either removed or explained.
Submitter's Proposal:
Either
- remove <sequence> construct
Or
- add rationale to explain it is syntactical sugar
Resolution: Proposed in message Neelakantan Kartha, 29 Aug 2003, approved at conf call 15 October 2003. (Previous approving Web ballot (ended 08 Oct 2003) was inquorate)

Add the following text in Section 12.

12 Structured Activities

... * Nondeterministic choice based on external events is provided by pick.

The set of structured activities in BPEL4WS is not intended to be the minimal required set. There are cases where one activity can replace another. For example, the sequence activity used to structure sequential processing may be emulated by a flow with additional links, to ensure sequential processing.

Structured activities can be used recursively.....

Issue 24: Separate schemas for executable vs abstract BPEL

To create 2 separate schemas for validating abstract and executable processes. Each schema would have its own URI. I will leave the question of if/how they extend a common base schema to whoever writes the things.
Links: Danny van der Rijn, 12 Jun 2003     John Evdemon, 12 Jun 2003     Announcement, 25 Jun 2003     Danny van der Rijn, 12 Dec 2003     Yaron Goland, 12 Dec 2003     John Evdemon, 12 Dec 2003     Danny van der Rijn, 13 Dec 2003     John Evdemon, 13 Dec 2003     Danny van der Rijn, 13 Dec 2003     Jim Clune, 15 Dec 2003     Satish Thatte, 16 Dec 2003     John Evdemon, 16 Dec 2003     Danny van der Rijn, 16 Dec 2003     Jim Clune, 16 Dec 2003     Satish Thatte, 18 Dec 2003     Eckenfels. Bernd, 18 Dec 2003     Proposed resolution (Danny van der Rijn, 7 Jan 2004)     David RR Webber, 7 Jan 2004     Discussed at 21 January 2004, deferred pending schema development     Philip Rossomando, 26 Jan 2004     Philip Rossomando, 2 Feb 2004     Philip Rossomando, 2 Feb 2004     Alex Yiu, 2 Feb 2004     Philip Rossomando, 6 Feb 2004     Diane Jordan, 6 Feb 2004     John Evdemon, 6 Feb 2004     Ben Bloch, 6 Feb 2004     John Evdemon, 6 Feb 2004     Alex Yiu, 6 May 2004     Alex Yiu, 11 May 2004     Alex Yiu, 11 May 2004
Changes: 4 Jul 2003 - fields: Document, Links;    31 Jul 2003 - fields: Champion;    13 Dec 2003 - fields: Links;    16 Dec 2003 - fields: Links;    23 Dec 2003 - fields: Links;    7 Jan 2004 - fields: Links, Status, Proposed resolution;    27 Jan 2004 - fields: Links;    2 Feb 2004 - fields: Links;    3 Feb 2004 - fields: Links;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Links;    6 May 2004 - fields: Links;    11 May 2004 - fields: Links

Issue 25: Consistent enablement of compensation handlers

<compensationHandler>
  <compensate/>
</compensationHandler>

Remove instance (process) compensation handlers
Remove the enableInstanceCompensation attribute
Rationale: See minutes of Melbourne and Walldorf meetings, and discussion under issue 53 : Include Business Transaction Management (BTM) constructs especially Process Coordination in BPEL Final.ppt (document details)
Links: Announcement, 26 Jun 2003     Satish Thatte, 11 Aug 2003     Assaf Arkin, 11 Aug 2003     Satish Thatte, 11 Aug 2003     Assaf Arkin, 11 Aug 2003     Satish Thatte, 11 Aug 2003     Assaf Arkin, 20 Aug 2003     Satish Thatte, 20 Aug 2003     Monica Martin, 26 Aug 2003     Satish Thatte, 15 Sep 2003     Assaf Arkin, 16 Sep 2003     Discussed at Redmond face-to-face     Proposed resolution (Yaron Y. Goland, 31 Mar 2004)     Discussed at Walldorf f-t-f (document details)     Discussed at 14 April con call (document details)     Web ballot (ended 28 Apr 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    12 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Links;    26 Aug 2003 - fields: Links;    15 Sep 2003 - fields: Links;    16 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    25 Mar 2004 - fields: Categories;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Rationale, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 26: Correlating use with receive/reply

Close with no change to the specification.

Links: Announcement, 26 Jun 2003     Danny van der Rijn, 5 Sep 2003     Monica Martin, 25 Sep 2003     Danny van der Rijn, 25 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    8 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links

Issue 27: Setting link status in case of transition condition

<scope name="X">
  <source link="A" transition=".."/>
  <source link="B"/>
  <compensationHandler/>
  .. do something
</scope>

The scope activity executes to completion. Some activities were performed that have side-effects and so a compensation handler was defined and got installed. The activity can now be compensated. The status of link B would be set to true, the status of link A would be set based on the value of the transition condition. The transition condition happens to generate a fault. What happens next?

A fault handler would be invoked in the enclosing scope and would compensate for the work done by the scope activity. If the targets of link A and link B are enclosed in the same scope then neither one would execute. But what if the target of link A and link B is in some other scope. What would be the status of the links? If the status of link A is true that may conflict with the intent of the transition condition that may set it to false realizing that some pre-condition has not been met. If the status of link A is false that would consist with the activity being compensated immediately after completion. But the case must be made that the status of link B should also be set to false for consistency.
Qualifier: clarification
Resolution: Proposed in Assaf Arkin, 1 Oct 2003, repeated in Assaf Arkin, 11 Oct 2003, decided at 15 October 2003, with the addition at the end

Add the following paragraph to the specification in the description of how links are handled (pages 64/65):

Note that the transition condition is evaluated after the activity has completed. If an error occurs while evaluating the transition condition, that error does not affect the completion status of the activity and is handled by the activity's enclosing scope. In the case of scopes, completion does not necessarily imply successful completion. A scope may suffer an internal fault and yet complete (unsuccessfully) if there is a corresponding fault handler associated with the scope and that fault handler completes without throwing a fault.

Yaron Goland and Assaf Arkin will ensure that appropriate text to note the implementation implications is included in the spec.
Links: Announcement, 26 Jun 2003     Satish Thatte, 15 Sep 2003     Discussed at Redmond face-to-face - see last slide of Satish's presentation (document details)     Assaf Arkin, 18 Sep 2003     Satish Thatte, 18 Sep 2003     Assaf Arkin, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Satish Thatte, 30 Sep 2003     Assaf Arkin, 30 Sep 2003     Satish Thatte, 30 Sep 2003     Proposed resolution (Assaf Arkin, 1 Oct 2003)     Repeat of proposed resolution (Assaf Arkin, 11 Oct 2003)     Ashwini Surpur, 16 Oct 2003     Prasad Yendluri, 16 Oct 2003     Satish Thatte, 17 Oct 2003     Ron Ten-Hove, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Assaf Arkin, 20 Oct 2003     Satish Thatte, 20 Oct 2003     Assaf Arkin, 21 Oct 2003     Satish Thatte, 23 Oct 2003     Maciej Szefler, 27 Oct 2003     Harvey Reed, 27 Oct 2003     Satish Thatte, 27 Oct 2003     Maciej Szefler, 27 Oct 2003     Maciej Szefler, 27 Oct 2003     Satish Thatte, 27 Oct 2003     Assaf Arkin, 27 Oct 2003     Assaf Arkin, 27 Oct 2003
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links, Proposed resolution;    26 Sep 2003 - fields: Links;    30 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Links, Status, Proposed resolution;    8 Oct 2003 - fields: Vote announcement;    11 Oct 2003 - fields: Proposed resolution, Links;    15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution;    17 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    23 Oct 2003 - fields: Links;    27 Oct 2003 - fields: Links;    9 Jun 2004 - fields: In spec

Issue 28: Simplification of join condition

Close with no change.
Links: Announcement, 26 Jun 2003     Satish Thatte, 15 Sep 2003     Assaf Arkin, 20 Oct 2003
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    20 Oct 2003 - fields: Links;    11 Nov 2005 - fields: Status, In spec, Resolution

Issue 29: Simplification of XPath expressions

getVariable( getVariable( 'name' ) )

An expression of this form is supported by the current specification, but hinders the ability to perform static analysis on the use of variables within the activity. This could be mitigated by clarifying the use of BPEL functions such that their input arguments must be literals. However, this goes against the XPath specification that makes no such restriction. An alternative would be to use XPath variables which are precluded from this dynamic behavior as per the XPath specification. (Assuming this restriction is still part of XPath 2.0 and XQuery).
Qualifier: enhancement
Depends on: Issue 103
Resolution: Proposed in Yaron Y. Goland, 15 Mar 2005, agreed conf call 6 April 2005
The resolution proposed was accepted unanimously during the TC teleconference held 6 April 2005, on the basis of also raising two new issues Issue 201 and Issue 202.

Links: Announcement, 26 Jun 2003     Satish Thatte, 15 Sep 2003     Next messages are in Issue 3 discussion     Yaron Goland, 8 Oct 2003     Edwin Khodabakchian, 8 Oct 2003     Satish Thatte, 8 Oct 2003     Danny van der Rijn, 8 Oct 2003     Assaf Arkin, 9 Oct 2003     Assaf Arkin, 20 Oct 2003     Yaron Goland, 21 Oct 2003     Proposed resolution (Yaron Y. Goland, 15 Mar 2005)     Assaf Arkin, 16 Mar 2005     Yaron Y. Goland, 21 Mar 2005     Assaf Arkin, 21 Mar 2005     Yaron Y. Goland, 22 Mar 2005     Assaf Arkin, 23 Mar 2005     Yaron Y. Goland, 24 Mar 2005     Assaf Arkin, 24 Mar 2005     Yaron Y. Goland, 29 Mar 2005     Assaf Arkin, 29 Mar 2005
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    9 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    16 Mar 2005 - fields: Links, Status, Proposed resolution;    21 Mar 2005 - fields: Links;    23 Mar 2005 - fields: Links;    25 Mar 2005 - fields: Links;    29 Mar 2005 - fields: Links;    9 May 2005 - fields: In spec

Issue 30: Support for coordination protocol

Clarify use of coordination protocol to:

• Establish a shared execution context with a shared outcome
• Cancellation of any pending work at the request of the coordinator
• Notification of completion or failure by the participant
• Compensation of any completed work at the request of the coordination
• Notification of (compensation) completion or failure by the participant

Clarify how a compensation handler in the process is used to invoke compensation handler of a service such coordinated. Clarify how the compensation handler of the process is invoked by such a service. Clarify how parameters are passed to and from compensation handler when invoked in such a manner.

Clarify the relationship between the scope in which an invocation is performed and the context that governs the coordination, where to wait for the completion of work by the participant, when to cancel such work, and how to be notified of general failure.

Also, investigate means to determine whether service supports coordination as part of the process definition (where only its interface is known), and how a process advertises this capability as part of its interface definition, e.g. using WSDL 1.2 F&P.
b>Revisitable: Yes
Qualifier: enhancement
Resolution: Proposed in Peter Furniss, 31 Mar 2004, decided by Web ballot (ended 28 Apr 2004) , after straw poll at Walldorf ftf

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Jun 2003     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (with issue 53) (document details)     Web ballot (ended 28 Apr 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    25 Mar 2004 - fields: Categories;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 31: Unique identifier for establishing new correlation

A generic solution would introduce a new function that would generate a unique value, e.g. a UUID. A more specific solution would grant the process a single unique value that could be, e.g. the process instance identifier, accessible from a function or contained in a well defined variable/property.

Another solution would have the process use a property from the input message that is equivalent to the message identifier as specified by WS-Addressing. However, a complication may occur if the process is instantiated by two concurrent receive activities, either of which can decide on the correlation set value to use.

Revisitable: Yes
Qualifier: enhancement
Resolution: Proposed verbally by Yaron Goland and decided at San Francisco f-t-f

Close with no change to spec.
Rationale: It can be assumed that platform-specific mechanisms are available to generate a unique identifier.
Links: Announcement, 26 Jun 2003
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    22 Jun 2004 - fields: In spec, Resolution, Rationale, Status, Revisitable

Issue 32: Link Semantics in Event Handlers

Each thread maintains its own copy of link status.

Specification to be aligned with this resolution.
Links: Yuzo Fujishima, 26 May 2003     Satish Thatte, 26 May 2003     Yuzo Fujishima, 2 Jul 2003     Edwin Khodabakchian, 2 Jul 2003     Yuzo Fujishima, 3 Jul 2003     Chunbo Huang, 3 Jul 2003     Edwin Khodabakchian, 3 Jul 2003     Announcement, 4 Jul 2003     Yuzo Fujishima, 5 Jul 2003     Dieter Roller, 5 Jul 2003     Frank Leymann, 5 Jul 2003     Francisco Curbera, 7 Jul 2003     Yuzo Fujishima, 7 Jul 2003     Yuzo Fujishima, 7 Jul 2003     Dieter Roller, 7 Jul 2003     Francisco Curbera, 7 Jul 2003     Assaf Arkin, 7 Jul 2003     Dieter Roller, 8 Jul 2003     Dieter Roller, 15 Sep 2003     Discussed at Redmond face-to-face - resolution to be proposed     Proposed resolution (Yuzo Fujishima, 27 Sep 2003)
Changes: 3 Jul 2003 - new issue;    4 Jul 2003 - fields: Links;    7 Jul 2003 - fields: Links;    9 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    27 Sep 2003 - fields: Links;    30 Sep 2003 - fields: Proposed resolution, Status;    1 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Resolution;    9 Jun 2004 - fields: In spec

Issue 33: Race condition before correlation set is established

Handling Callbacks in a Business Process (especially if it is done as suggested in the Initial Example of the 1.1 Spec) is depending on unspecified runtime engine behavior.

If we assume, that a new entry for a correlation set is entered on activation of the receive, and we also assume, that incoming web service requests on ports which have no matching correlation are rejected, we have a small window in the system, where a particular information was requested, but the related receive activity was not yet activated. This could be, because the requested party will answer, before the SOAP communication was finished, it could also be, because the runtime engine is loaded, to not enable the receive fast enough. It could also be because the runtime engine was putting the process to sleep because or priority issues.

The specification should either enforce a semantic which will allow <sequence><invoke><receive></sequence> process, and force implementers to keep that case in mind, or the specification should endorse (and then actually use in its own samples) an alternative way.

Please keep in mind, that it might not be enough to assure, that implementations can handle the response to an invoke of the directly following activity. Flows and sub process could be involved, too. In the case of flows, the current spec does not assume any implementations, which is good for implementing conforming engines, but it is also bad for specific modeling techniques which may be unsafe to use. A good sample would be a <flow><receive /><invoke /></flow> which also has the same (maybe even bigger) race condition window to allow callbacks.

A process which creates a correlation id, waits for the response and then invokes the service is a typical use case. Issue 31 is a feature request which would depend on this, and will suffers from the same unspecified behavior.

Alternative solution (which is a bit overhead, unfortunately): allow a new link type "ready to receive" from receive components to invoke components, which will be enabled, as soon as the corresponding correlation entry is made, and the system is listening for the callback. Brainstorming welcome.
Resolution: Proposed in Eckenfels. Bernd, 14 Apr 2004, decided by Web ballot (ended 28 Apr 2004)

Include an explanation (final wording from the editing team), that it is accepted that messages with legal outstanding correlations may arrive after the correlation set is instantiated but before the actual receive is activated and that such messages should be processed. Modellers can assume that it is safe to rely on this (since there is no bpel construct to implement it otherwise).

There is no need for a precise definition of when it is legal/required for the engine to to look ahead and what timeouts to assume. Therefore it is not possible to include samples like "receive or a callback in a sequnece directly after the invoke". The text should address the modeller's expectations and not to explicitly define requirements to the engine, since we are not yet down that conformance definition road in other places.

There are other places where the bpel spec does not require a specific timing (e.g. invoke and receive in parallel in a flow), where the same expectations of the modeller should be acknolwledged.
Vote announcement: Web ballot (ends 28 Apr 2004)
Links: issue 31 : Unique identifier for establishing new correlation     Announcement, 9 Jul 2003     Eckenfels. Bernd, 10 Jul 2003     Eckenfels. Bernd, 12 Aug 2003     Proposed resolution (Eckenfels. Bernd, 29 Mar 2004)     Revised proposal (Eckenfels. Bernd, 14 Apr 2004)     Eckenfels. Bernd, 14 Apr 2004     Kevin Liu, 27 Apr 2004     Eckenfels. Bernd, 28 Apr 2004
Changes: 9 Jul 2003 - new issue;    10 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    12 Aug 2003 - fields: Links;    29 Mar 2004 - fields: Links, Status, Proposed resolution;    15 Apr 2004 - fields: Proposed resolution, Links;    22 Apr 2004 - fields: Vote announcement;    29 Apr 2004 - fields: Links, Status, Proposed resolution, Resolution;    20 Jun 2004 - fields: In spec

Issue 34: Dependency on Proprietary Specifications

A "service-ref" wrapper will be defined:

<xs:element name="service-ref" type= tns:ServiceRefType />
<xs:complexType name="ServiceRefType">
    <xs:sequence>
        <xs:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="1"/>
    </xs:sequence>
<xs:attribute name="reference-scheme" type="xs:anyURI" use="required"/>
</xs:complexType>

The partnerlink should contain this "service-ref" element for the endpoint references of partnerRole or myRole.

e.g.:

<service-ref reference-scheme="http://foo.org">
   <foo:barEPR xmlns:foo="http://foo.org"> ... </foo:barEPR>
</service-ref>

When including this in the spec., the editing team will include explanations of error handling and the motivation for this construct. The solution will include a clarification to the reference-scheme attribute.
Rationale: It may take more than few months for the industry to converge on ONE single addressing or EPR scheme. Instead of keep delaying BPEL TC itself, we should leave it open. And let the industry take its own course to find out its convergence point. BPEL spec should be as flexible as possible to allow the convergence happen.

Even after the industry has converged into one addressing or EPR scheme in future, we may still need to face the versioning issue.

For WSA alone, we already have two versions floating around:
http://schemas.xmlsoap.org/ws/2003/03/addressing
http://schemas.xmlsoap.org/ws/2004/03/addressing

WSA by itself already presents us the version conversion problem. The solution of this problem would require the semantics listed above.
Links: Ron Ten-Hove, 16 May 2003     Announcement, 9 Jul 2003     Monica J. Martin, 31 Mar 2004     Monica J. Martin, 1 Apr 2004     Ron Ten-Hove, 6 May 2004     Proposed resolution (Ron Ten-Hove, 7 May 2004)     Yaron Y. Goland, 14 May 2004     Ron Ten-Hove, 17 May 2004     Yaron Y. Goland, 18 May 2004     Proposed resolution (Yaron Y. Goland, 18 May 2004)     Ron Ten-Hove, 18 May 2004     Francisco Curbera, 19 May 2004     Frank Ryan, 19 May 2004     Ron Ten-Hove, 19 May 2004     John Evdemon, 19 May 2004     Ron Ten-Hove, 19 May 2004     Ron Ten-Hove, 19 May 2004     Steve Ross-Talbot, 19 May 2004     John Evdemon, 19 May 2004     Assaf Arkin, 19 May 2004     Francisco Curbera, 25 May 2004     Ron Ten-Hove, 25 May 2004     Yaron Y. Goland, 26 May 2004     Satish Thatte, 26 May 2004     Martin Chapman, 26 May 2004     Satish Thatte, 26 May 2004     Ugo Corda, 26 May 2004     Monica J. Martin, 26 May 2004     Satish Thatte, 26 May 2004     Jeff Mischkinsky, 28 May 2004     Jeff Mischkinsky, 28 May 2004     Monica J. Martin, 28 May 2004     Francisco Curbera, 29 May 2004     Peter Furniss, 30 May 2004     Alex Yiu, 21 Jun 2004     Ron Ten-Hove, 22 Jun 2004     Alex Yiu, 30 Jun 2004     Ron Ten-Hove, 30 Jun 2004     John Evdemon, 1 Jul 2004     Prasad Yendluri, 2 Jul 2004     Alex Yiu, 3 Jul 2004     Prasad Yendluri, 3 Jul 2004     Alex Yiu, 14 Jul 2004     Prasad Yendluri, 14 Jul 2004     Ron Ten-Hove, 14 Jul 2004     Alex Yiu, 15 Jul 2004     Prasad Yendluri, 15 Jul 2004
Changes: 9 Jul 2003 - new issue;    10 Jul 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    31 Mar 2004 - fields: Links;    1 Apr 2004 - fields: Links;    6 May 2004 - fields: Links, Status, Proposed resolution;    8 May 2004 - fields: Links, Status, Proposed resolution;    15 May 2004 - fields: Links;    18 May 2004 - fields: Links, Status, Proposed resolution;    19 May 2004 - fields: Links;    20 May 2004 - fields: Links;    25 May 2004 - fields: Links;    26 May 2004 - fields: Links;    27 May 2004 - fields: Links;    30 May 2004 - fields: Links;    2 Jun 2004 - fields: Links, Proposed resolution;    16 Jun 2004 - fields: Categories;    22 Jun 2004 - fields: Links;    23 Jun 2004 - fields: Status, Vote, Resolution, Rationale;    30 Jun 2004 - fields: Links;    1 Jul 2004 - fields: Links;    3 Jul 2004 - fields: Links;    16 Jul 2004 - fields: Links;    17 Aug 2004 - fields: In spec

Issue 35: Support for modeling

A more detailed explanation is provided by Frank Leymann at the end of Frank Leymann, 6 Jul 2003
Qualifier: enhancement
Resolution: Proposed in Satish Thatte, 22 Jan 2004, decided 4 February 2004 con call

Close with no change to the specification.
Rationale: while modeling is a very important requirement it is a big and non-trivial requirement that goes well beyond what we have set ourselves as goals. Assaf Arkin originally opened the issue and he agreed with me in e-mail that the issue should be closed with no changes to the spec since the issue has been dormant anyway. There was no additional discussion.
Links: Announcement, 9 Jul 2003     Proposed resolution (Satish Thatte, 22 Jan 2004)
Changes: 9 Jul 2003 - new issue;    10 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    22 Jan 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 36: Multiple instances of event handler

An input message targeting that event handler is received by the process (M1). A new instance of the event handler is started, the message is assigned to the specified variable and work begins based on the value of that variable.

At which point another input message targeting the same event handler is recieved by that process (M2). A new instance of the event handler is started, the message is assigned to the specified variable and work begins based on the value of that variable.

Except that the first instance has not completed all work yet. While it started performing some work using the variable value from M1, it suprisingly finds that the new value of the variable is coming from M2.

Currently the spec does not indicate that these two instances will be serialized with respect to each other, nor that these two variables are distinct and not the same (variable instances are per process or some enclosing scope). Scoping does not alleviate the race condition since a new scope must be created and the values assigned to its variables, giving enough overlap between the two instances for a race condition to exist.

There seems to be no measure in the spec that allows for multiple instances of an event handler to occur concurrently, yet the spec suggests that this is possible.
Qualifier: enhancement, clarification
Related issue: issue 79 : Serializable scopes do not need to be leaf scopes
Resolution: Proposed in Assaf Arkin, 11 Oct 2003, decided at 15 October 2003

The semantics of event handler would be changed to allow the variable used to capture the input message to be treated local to the event handler instance:

1. Rename eventHandler/onMessage to eventHandler/onEvent

2. The name of the variable is given in the variable attribute.

3. The attribute messageType specifies the variable type by referencing the message type definition using its QName.

4. The variable type must be the same as the type of the input message defined by referenced operation.

5. The event handler declares a variable of that name and type that is scoped to the event handler activity.

6. Upon receipt of the input message the event handler assigns the input message to the variable before proceeding to perform the event handler activity.

7. Since the variable is scoped to that activity, two instances of the activity (whether executed seriallly or concurrently) do not operate on the same variable.

The above is a statement of the intent, the editing group will review the text with the issue champion, Assaf Arkin
Links: Announcement, 9 Jul 2003     Dieter Roller, 18 Jul 2003     Edwin Khodabakchian, 18 Jul 2003     Monica J. Martin, 18 Jul 2003     Edwin Khodabakchian, 1 Aug 2003     Dieter Roller, 15 Sep 2003     Discussed at Redmond face-to-face     Maciej Szefler, 19 Sep 2003     Edwin Khodabakchian, 19 Sep 2003     Francisco Curbera, 21 Sep 2003     Edwin Khodabakchian, 21 Sep 2003     Maciej Szefler, 22 Sep 2003     Steve Brown, 22 Sep 2003     Edwin Khodabakchian, 22 Sep 2003     Satish Thatte, 22 Sep 2003     Francisco Curbera, 24 Sep 2003     Maciej Szefler, 25 Sep 2003     Maciej Szefler, 25 Sep 2003     Yaron Goland, 25 Sep 2003     Satish Thatte, 25 Sep 2003     Maciej Szefler, 25 Sep 2003     Satish Thatte, 25 Sep 2003     Monica Martin, 26 Sep 2003     Assaf Arkin, 26 Sep 2003     Assaf Arkin, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Edwin Khodabakchian, 26 Sep 2003     Assaf Arkin, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Edwin Khodabakchian, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Edwin Khodabakchian, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Assaf Arkin, 26 Sep 2003     Satish Thatte, 26 Sep 2003     Assaf Arkin, 30 Sep 2003     Edwin Khodabakchian, 30 Sep 2003     Assaf Arkin, 30 Sep 2003     Satish Thatte, 30 Sep 2003     Edwin Khodabakchian, 30 Sep 2003     Assaf Arkin, 30 Sep 2003     Satish Thatte, 30 Sep 2003     Proposed resolution (Assaf Arkin, 1 Oct 2003)     Satish Thatte, 1 Oct 2003     Yaron Goland, 1 Oct 2003     Assaf Arkin, 2 Oct 2003     Harvey Reed, 2 Oct 2003     Assaf Arkin, 2 Oct 2003     Harvey Reed, 2 Oct 2003     Danny van der Rijn, 2 Oct 2003     Francisco Curbera, 3 Oct 2003     Assaf Arkin, 3 Oct 2003     Edwin Khodabakchian, 3 Oct 2003     Satish Thatte, 3 Oct 2003     Revised proposed resolution (Assaf Arkin, 11 Oct 2003)     Prasad Yendluri, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Assaf Arkin, 17 Oct 2003
Changes: 9 Jul 2003 - new issue;    10 Jul 2003 - fields: Links;    20 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    1 Aug 2003 - fields: Links;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    20 Sep 2003 - fields: Links;    22 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    25 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Links, Status, First proposed resolution;    2 Oct 2003 - fields: Links;    3 Oct 2003 - fields: Links;    6 Oct 2003 - fields: Links;    8 Oct 2003 - fields: Vote announcement;    11 Oct 2003 - fields: Links, Proposed resolution;    15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution;    17 Oct 2003 - fields: Links;    12 Nov 2003 - fields: Related issue;    9 Jun 2004 - fields: In spec

Issue 37: Initiating Correlation Set More Than Once

What will happen if a correlation set is initiated more than once during the lifetime of the corresponding scope?

Quote from 10.2 Defining and Using Correlation Sets:

After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until its completion.

Candidates are:

A. bpws:correlationViolation fault is always thrown.

B. bpws:correlationViolation fault is thrown only if the new property values are different from the old ones.

C. The old property values remain valid and no fault is thrown. The new property values are ignored.
Resolution: Proposed in Alex Yiu, 23 Jun 2004, decided at San Francisco f-t-f

The "initiate" attribute becomes a tri-value switch instead of a boolean switch. The legal values of the "initiate" attribute are: "yes", "rendezvous", "no". The default value of the attribute remains "no".

After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until the completion of the scope. This correlation consistency constraint must be observed in all cases of "initiate" values.

• When the "initiate" attribute is set to "yes", the related activity MUST attempt to initiate the correlation set.
  • If the correlation set is already initiated and the "initiate" attribute is set to "yes" , the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.
• When the "initiate" attribute is set to "rendezvous", the related activity MUST attempt to initiate the correlation set, if the correlation set is NOT initiated yet.
  • If the correlation set is already initiated and the "initiate" attribute is set to "rendezvous", the correlation consistency constraint MUST be observed. If the constraint is violated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.
• When the "initiate" attribute is set to "no", the related activity MUST NOT attempt to initiate the correlation set.
  • If an activity with the "initiate" attribute set to "no" attempts to use a correlation set that has not been previously initiated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.
  • If the correlation set is already initiated and the "initiate" attribute is set to "no", the correlation consistency constraint MUST to be observed. If the constraint is violated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.

Affected Sections:

• 6.2. The Structure of a Business Process
• 10.2. Defining and Using Correlation Sets
• 14.4. Correlation
• Appendix D. XSD Schema

Issue 38: Directed Activity Graph and block structured

There may be good rationale for supporting such constructs. However, no good rationale has been given in the spec. An explicit description of the rationale for including such redundancy, or the purpose it serves would be helpful in weighing up other changes to the specification.
Qualifier: clarification
Resolution: Proposed in Yaron Goland, 19 Jan 2004, decided 4 February 2004 con call

Close with no change to the specification.
Rationale: I (Yaron) talked with Assaf Arkin, who opened the issue and he agreed that the resolution to issue 23 : Rationale for sequence vs. flow also resolved this issue. Therefore he agrees to having this issue closed without change to the specification.
Links: Announcement, 13 Jul 2003     Proposed resolution (Yaron Goland, 19 Jan 2004)
Changes: 13 Jul 2003 - new issue;    13 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    20 Jan 2004 - fields: Links, Status, Proposed resolution;    4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 39: Inconsistent syntax for query attribute values in spec examples

On page 38:

<bpws:propertyAlias propertyName="tns:taxpayerNumber" 
        messageType="txmsg:taxpayerInfo" part="identification" 
        query="/socialsecnumber"/> 

On page 49:

<bpws:propertyAlias propertyName="cor:customerID" 
        messageType="tns:POMessage" part="PO" 
        query="/PO/CID"/> 

On page 92:

<bpws:propertyAlias propertyName="tns:shipOrderID" 
        messageType="sns:shippingNoticeMsg" 
        part="shipNotice" 
        query="/ShipNoticeHeader/shipOrderID"/> 

It seems that the example on page 49 is correct and the other ones are wrong.

In fact, sec. 14.3, Assignment, says:

"For XPath 1.0, the value of the query attribute MUST be an absolute locationPath (with '/' meaning the root of the document fragment representing the entire part). It is used to identify the root of a subtree within the document fragment representing the part."

"The interpretation of the message, part, and query attributes is the same as in the corresponding from-spec in copy assignments (see Assignment).

See text in message Ugo Corda, 18 Aug 2003

Issue 40: attribute name "variable" or "message"

Close with no change to the specification.
Rationale: The issue was originally opened by Peter Furniss based on a complaint by Alastair Green. I (Yaron) talked with Peter and he agreed that he has gotten used to the naming and so has no objections to the issue being closed with no action.
Links: Announcement, 24 Jul 2003     Proposed resolution (Yaron Goland, 19 Jan 2004)     Peter Furniss, 22 Jan 2004     Satish Thatte, 26 Jan 2004
Changes: 24 Jul 2003 - new issue;    25 Jul 2003 - fields: Links;    20 Jan 2004 - fields: Links, Status, Proposed resolution;    23 Jan 2004 - fields: Links;    26 Jan 2004 - fields: Links;    4 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale;    9 Jun 2004 - fields: In spec

Issue 41: onMessage handler definition

The editorial error on page 25 will be corrected to align with the definition on page 80
Links: Announcement, 31 Jul 2003     Discussed at Redmond face-to-face - resolution to be proposed     Ram Jeyaraman, 21 Sep 2003     Satish Thatte, 23 Sep 2003     John Evdemon, 23 Sep 2003
Changes: 31 Jul 2003 - new issue;    31 Jul 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    18 Sep 2003 - fields: Links;    22 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    24 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Status, Resolution;    9 Jun 2004 - fields: In spec

Issue 42: Need for Formalism

Close without change to the specification.
Rationale: Although the use and definitions of formalisms can be useful in understanding and defining a specification, including such in a formal description as normative in a specification that is also in natural language and less formal expressions has the drawbacks:

1. it is a very large effort, and can significantly delay the completion of the specification
2. formal specifications tend to be understood only by a few and many of the subject-area experts will use and think in terms of the non-formal description, in development of both the specification and implementations.
3. if there is conflict between the formal and non-formal which is to have precedence ?

Separate formal descriptions of bpel, not included in the specification and without normative authority are encouraged. The TC will establish a publically-accessible space in the website for supplementary information on formalism with appropriate links.
Links: Sid Askary, 28 Jul 2003     Steve Ross-Talbot, 28 Jul 2003     Ron Ten-Hove, 28 Jul 2003     Announcement, 31 Jul 2003     Proposed resolution (Peter Furniss, 20 Feb 2004)     Peter Furniss, 20 Feb 2004     Satish Thatte, 22 Feb 2004     Frank Leymann, 22 Feb 2004     Ron Ten-Hove, 23 Feb 2004
Changes: 31 Jul 2003 - new issue;    31 Jul 2003 - fields: Links;    23 Feb 2004 - fields: Links, Status, Proposed resolution;    25 Feb 2004 - fields: Links;    3 Mar 2004 - fields: Status, Proposed resolution, Resolution, Rationale, Revisitable

Issue 43: Setting up Periodic Alarms

<onAlarm for="duration-expr"?
     until="deadline-expr"?
     repeat="duration-expr"?
     frequency="cardinal-expr"?>*
         alarmActivity
</onAlarm>

The text as proposed (and copied here) will be modified in line with the resolution of issue 13 : Future Usage of XPATH 2.0 and XQuery 1.0 , changing the attributes to elements.

The syntax for onAlarm element be changed to:

<onAlarm for="duration-expr"? until="deadline-expr"? 
repeatEvery="duration-expr"?>
    activity
</onAlarm>

If one of "for" or "until" attributes and "repeatEvery" are present, the event handler is not created until the "for" or "until" attribute time; thereafter it is recreated at the interval defined by "repeatEvery".
Links: Ram Jeyaraman, 29 Jul 2003     Dieter Roller, 29 Jul 2003     Ram Jeyaraman, 29 Jul 2003     Announcement, 31 Jul 2003     Discussed at Redmond face-to-face     Ram Jeyaraman, 21 Sep 2003     Satish Thatte, 23 Sep 2003     Ben Bloch, 23 Sep 2003     Satish Thatte, 23 Sep 2003     Ben Bloch, 24 Sep 2003     Satish Thatte, 24 Sep 2003     Ram Jeyaraman, 24 Sep 2003     Proposed resolution (Yaron Y. Goland, 16 Jun 2004)     Satish Thatte, 18 Jun 2004     Yaron Y. Goland, 21 Jun 2004     Edwin Khodabakchian, 21 Jun 2004     Frank Leymann, 22 Jun 2004
Changes: 31 Jul 2003 - new issue;    31 Jul 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    18 Sep 2003 - fields: Links;    22 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    24 Sep 2003 - fields: Links;    17 Jun 2004 - fields: Links, Status, Proposed resolution;    19 Jun 2004 - fields: Links;    22 Jun 2004 - fields: Links;    24 Jun 2004 - fields: Status, Proposed resolution, Resolution;    17 Aug 2004 - fields: In spec

Issue 44: portType is duplicated on Invoke activity and partnerLinkType

A partnerLinkType do refer to a maximum of two portTypes. Assuming that a process does not invokes itself, then the Invoke refers to the partnerRole, not myRole, so there is only one possible portType, for that Invoke. In the other hand, if we assume the process can invoke itself, then it will be better to specify the role in the Invoke activity instead of the portType, because role has process semantics instead of the portType.
Submitter's Proposal: I propose that portType on the Invoke activity be removed and instead an optional role be included instead. When the role is specified, it must correspond to one of the two roles defined in the partnerLink. If the role is not specified the partnerRole in the partnerLink should be assumed.
First resolution: proposed in message Mike Marin, 19 Aug 2003, decided in TC conf call, 20 August 2003

Remove the portType from the invoke activity and use the portType that corresponds to the partnerRole in the partnerLink.

This covers most if not all the use cases. With the only exception of a process that wants to call itself, which is discussed by issue 52

It is moved that the portType attribute be made optional.

If the portType attribute is included in a message activity then the value of the portType attribute MUST match the portType value implied by the combination of explicitly specified partnerLink and the role implicitly specified by the message activity. A failure to match as previously described MUST result in a static checking error.
Links: Announcement, 5 Aug 2003     Satish Thatte, 11 Aug 2003     Satish Thatte, 11 Aug 2003     Mike Marin, 11 Aug 2003     Satish Thatte, 11 Aug 2003     Yaron Goland, 12 Aug 2003     Satish Thatte, 12 Aug 2003     Eckenfels. Bernd, 12 Aug 2003     Danny van der Rijn, 12 Aug 2003     Yaron Goland, 13 Aug 2003     Satish Thatte, 14 Aug 2003     Monica Martin, 17 Aug 2003     Mike Marin, 19 Aug 2003     see also issue 52     Yaron Goland, 19 Aug 2003     Mike Marin, 19 Aug 2003     Yaron Goland, 19 Aug 2003     Kevin Liu, 16 Oct 2003     Satish Thatte, 16 Oct 2003     Chris Keller, 16 Oct 2003     Kevin Liu, 16 Oct 2003     Satish Thatte, 16 Oct 2003     Yaron Goland, 20 Oct 2003     Proposed resolution (Yaron Y. Goland, 4 Jun 2004)
Changes: 5 Aug 2003 - new issue;    5 Aug 2003 - fields: Links;    12 Aug 2003 - fields: Links;    14 Aug 2003 - fields: Links;    18 Aug 2003 - fields: Links;    19 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Status, Resolution;    16 Oct 2003 - fields: Links;    17 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    4 Nov 2003 - fields: Status, First resolution (renamed from Resolution), Reopened;    9 Jun 2004 - fields: Links, Status, Proposed resolution;    22 Jun 2004 - fields: Status, Proposed resolution, Resolution;    17 Aug 2004 - fields: In spec

Issue 45: Wording of "while" activity

"The while activity supports repeated performance of a specified iterative activity. The iterative activity is performed until the given Boolean while condition no longer holds true."

The use of the word "until" in the description can cause the reader to conflate the semantics of the "while" activity with a (currently) non-existent "repeat-until" activity that evaluates the condition after the loop has executed, and therefore always executes at least once.
Submitter's proposal: Change the wording to read:

"The while activity supports repeated performance of a specified iterative activity. The iterative activity is performed as long as the given Boolean while condition holds true."

To be referred to the editorial committee.

Issue 46: Namespace for the document fragment representing a part

In XPath 1.0 there is no default namespace for evaluation meaning that all names need to be qualified with a prefix. In XPath 2.0 there is the use of a default namespace, but this specification is referencing 1.0. Putting that aside for a moment in both 1.0 and 2.0 no namespace is not equal to default namespace. Let's take an example:

  <message name="poMessage"> 
    <part name="PO" type="tns:purchaseOrder"/> 
  </message> 


  <bpws:property name="poNumber" type="xsd:positiveInteger"/> 


  <bpws:propertyAlias propertyName="tns:poNumber"   
       messageType="tns:poMessage" part="PO" 
       query="/PO/Header/PONumber"/> 


  </bpws:propertyAlias> 

If as suggested in issue 39 we assume that the Part PO is included in the query and has no namespace (namespace URI is null) association. This query in order to be correct in XPath should be formulated as:

 /PO/tns:Header/tns:PONumber 

Note the section Node Tests from XPath 1.0 – section 2.3 Node Tests)

"A node test that is a QName is true if and only if the type of the node (see [5 Data Model]) is the principal node type and has an expanded-name equal to the expanded-name specified by the QName. For example, child::para selects the para element children of the context node; if the context node has no para children, it will select an empty set of nodes. attribute::href selects the href attribute of the context node; if the context node has no href attribute, it will select an empty set of nodes.

A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration n the expression context."

Note the statement "except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null"

Now in XPath 2.0 it is slightly different (XPath 2.0 section 3.2.1.2 Node Tests)

"A node test that consists of a QName is called a name test. A name test is true if and only if the kind of the node is the principal node kind and the expanded-QName of the node is equal to the expanded-QName specified by the name test. For example, child::para selects the para element children of the context node; if the context node has no para children, it selects an empty set of nodes. attribute::abc:href selects the attribute of the context node with the QName abc:href; if the context node has no such attribute, it selects an empty set of nodes.

A QName in a name test is expanded into an expanded-QName using the in-scope namespaces in the expression context. It is a static error if the QName has a prefix that does not correspond to any in-scope namespace. An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespaceURI of the default element namespace in the expression context; otherwise, it has no namespaceURI."

Note the statement: "An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespaceURI of the default element namespace in the expression context; otherwise, it has no namespaceURI."

So in either case we need to qualify the namespace for your message part declared as a type example. And if we are following the XPath 1.0 specification we should qualify all elements that have a namespace since no default namespace is applied. In this case basically every query in the bpel specification is incorrect and should contain prefixes for all element names associated with namespaces in the XPath expressions.
Resolution: Proposed in Francisco Curbera, 24 Sep 2003, decided at 15 October 2003

The document fragment for a message part declared as a type is represented in XPath expressions (inside a "query" attribute) as an element with local name equal to the part name (this is according to the resolution of issue 39.) In addition, the namespace URI of that element is considered to be a null URI.

Issue 47: Which Version of WSDL should we use?

WSDL1.2 is still under construction, but it's already obvious that some key changes will be made to the core WSDL language. For example, portType will be called "interface", support for interface inheritance (sort of) will be added, and most importantly for BPEL, the message construct will most likely be removed (the W3C web services description WG has just reached consensus in its F2F last week that). Hopefully the public will have access to a relatively stable draft by November as the W3C group is targeting to produce a last call draft by then.

We are facing a timing issue here. Our charter gives us 9 months to produce a TC draft. Let's assume that we will get the job done on time J , and we will have a new version of BPEL delivered in February 2004. Though nobody can tell for sure at this point of time, but it's likely that WSDL1.2 (at least part 1 for the core language) may be released in about the same time frame, if not earlier. If we will not be able to meet our deadline in February, WSDL1.2 may already been there for a little while when we do our release.

I would like suggest that the TC consider to:

1. Assess the necessity for establishing a form liaison with the W3C WSD working group to coordinate schedules and get updates on key feature changes

2. Assess the impact of relevant WSDL changes on BPEL
Resolution: Proposed in Kevin Liu, 4 Oct 2003, decided at 15 October 2003

This issue was created to have a general discussion about what to do with WSDL1.2 (or whatever version number W3C WSD WG may call it eventually, same below)

As discussed in the Redmond F2F (Kevin Liu, 22 Sep 2003) and the Oct.1 con call, we agreed not to use WSDL1.2 for WSBPEL since it is still under construction and its availability is still uncertain.

We will try to align with WSDL1.2 work via identifying and addressing particular relevant feature changes. issue 71 : Removal of wsdl:message and issue 15 : WSDL MEPs will be used to clarify potential impacts of removal of message construct and WSDL1.2 patterns

Issue 47 closed without specific change to the specification.

Links: Announcement, 8 Aug 2003     Kevin Liu, 15 Sep 2003     Discussed at Redmond face-to-face     First proposed resolution (Kevin Liu, 22 Sep 2003)     Discussed at TC conf call, 1 October 2003     see also issue 15     see also issue 71        see also issue 72        Much of the discussion on issue 72 has a subject line identifying this issue     Revised proposed resolution (Kevin Liu, 4 Oct 2003)     Eckenfels. Bernd, 6 Oct 2003
Changes: 8 Aug 2003 - new issue;    8 Aug 2003 - fields: Links;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Links;    2 Oct 2003 - fields: Links;    3 Oct 2003 - fields: Links;    6 Oct 2003 - fields: Links;    8 Oct 2003 - fields: Vote announcement;    15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution

Issue 48: XML Transform Support

Closed with no change to the spec.
Resolution: Included in resolution of issue 11 : Query in <to> close should allow assigning to new locations
Rationale: With the agreed resolution of issue 13 : Future Usage of XPATH 2.0 and XQuery 1.0 it is now possible to add in support for languages such as XQUERY. (See also discussion in Yaron Y. Goland, 25 Mar 2004 and messages referenced from that)
Proposal to re-open: Ron Ten-Hove, 8 Nov 2005

Following resolution of issue 11 : Query in <to> close should allow assigning to new locations
Links: Announcement, 12 Aug 2003     issue 11 : Query in <to> close should allow assigning to new locations     Yaron Goland, 11 Aug 2003     Yaron Goland, 13 Aug 2003     Proposed resolution (Yaron Y. Goland, 25 Mar 2004)     Danny van der Rijn, 25 Mar 2004     Yaron Y. Goland, 25 Mar 2004     Discussed at Walldorf f-t-f (document details)     Ballot result (Ron Ten-Hove, 8 Nov 2005)
Changes: 12 Aug 2003 - new issue;    12 Aug 2003 - fields: Links;    14 Aug 2003 - fields: Links;    25 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Rationale;    9 Nov 2005 - fields: Links, Status, Proposal to re-open;    16 Nov 2005 - fields: Resolution, Status, In spec

Issue 49: Disambiguating <receive>s to <reply> to

Closed as a duplicate of 26.
Links: Announcement, 12 Aug 2003     Dieter Roller, 14 Aug 2003     Danny van der Rijn, 14 Aug 2003     Dieter Roller, 17 Aug 2003     Monica Martin, 17 Aug 2003     Danny van der Rijn, 18 Aug 2003     Danny van der Rijn, 4 Sep 2003     Danny van der Rijn, 5 Sep 2003     Dieter Roller, 7 Sep 2003     Danny van der Rijn, 8 Sep 2003     Monica Martin, 25 Sep 2003     Danny van der Rijn, 25 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Proposed resolution (Danny van der Rijn, 14 Jan 2004)
Changes: 12 Aug 2003 - new issue;    12 Aug 2003 - fields: Links;    14 Aug 2003 - fields: Links;    18 Aug 2003 - fields: Links;    19 Aug 2003 - fields: Links;    8 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    14 Jan 2004 - fields: Links, Status, Proposed resolution;    15 Jan 2004 - fields: Links;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution

Issue 50: Semantics for "dangling receive"

A receive activity for an inbound request/response operation is said to be *open* if that activity has been executed and no corresponding reply activity has been executed. A fault bpel:missingReply is thrown if the process instance reaches the end of its execution, and one or more receive activities remain open. This fault indicates a modeling error that was not detected by static analysis.

Issue 51: Section 9.3.1 & Schema Validation

Update Section 9.3.2, "Type Compatibility in Assignment", as follows:

Update the section title to "Type Compatibility in Copy Operations"

Update the first paragraph of the section and first two bullet items following to read (changes denoted by italics):

For a copy operation to be valid, the data referred to by the from and to specifications MUST be of compatible types. The following points make this precise:

• The selection result of the from-spec is a variable of a WSDL message type, and the selection result of the to-spec is a variable of a WSDL message type. In this case, both variables MUST be of the same message type, where two message types are said to be equal if their qualified names are the same.

• The selection result of the from-spec is a variable of a WSDL message type, and the selection result of the is not, or vice versa. This is not legal because parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly.

Remove the third bullet item

Remove the last paragraph of the section.
Links: Yaron Goland, 8 Aug 2003     Announcement, 18 Aug 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Discussed at Walldorf f-t-f (document details)     see rationale in issue 100     Dieter Koenig1, 24 Nov 2004     Alex Yiu, 24 Aug 2005     Alex Yiu, 25 Aug 2005     Yaron Y. Goland, 12 Sep 2005     Alex Yiu, 13 Sep 2005     Eckenfels. Bernd, 13 Sep 2005
Changes: 18 Aug 2003 - new issue;    18 Aug 2003 - fields: Links;    15 Jan 2004 - fields: Links;    22 Apr 2004 - fields: Links;    23 Jun 2004 - fields: Links;    25 Nov 2004 - fields: Links;    25 Aug 2005 - fields: Links;    29 Aug 2005 - fields: Links;    14 Sep 2005 - fields: Links;    19 Sep 2005 - fields: Status, Resolution;    20 Oct 2005 - fields: In spec

Issue 52: Specify how flows in the same process send messages to each other

Close with no change to spec.
Links: Announcement, 18 Aug 2003     Yaron Goland, 18 Aug 2003     split from issue 44     Maciej Szefler, 20 Aug 2003     Satish Thatte, 20 Aug 2003     Danny van der Rijn, 20 Aug 2003     Tony Andrews, 20 Aug 2003     Yaron Goland, 20 Aug 2003     Edwin Khodabakchian, 20 Aug 2003     Yaron Goland, 20 Aug 2003     Edwin Khodabakchian, 20 Aug 2003     Yaron Goland, 20 Aug 2003     Ugo Corda, 20 Aug 2003     Danny van der Rijn, 20 Aug 2003     Eckenfels. Bernd, 21 Aug 2003     Satish Thatte, 23 Aug 2003     Yaron Goland, 26 Aug 2003     Satish Thatte, 26 Aug 2003     Assaf Arkin, 26 Aug 2003     Ron Ten-Hove, 27 Aug 2003     Satish Thatte, 27 Aug 2003     Ron Ten-Hove, 27 Aug 2003     Sazi Temel, 28 Aug 2003     Satish Thatte, 28 Aug 2003     David RR Webber, 30 Aug 2003     Yaron Goland, 2 Sep 2003     David RR Webber, 3 Sep 2003     Frank Leymann, 3 Sep 2003     Monica Martin, 3 Sep 2003     David RR Webber, 3 Sep 2003     Yaron Goland, 3 Sep 2003     Assaf Arkin, 3 Sep 2003     Yaron Goland, 29 Sep 2003     Satish Thatte, 30 Sep 2003     Yaron Goland, 30 Sep 2003     Satish Thatte, 30 Sep 2003     Edwin Khodabakchian, 30 Sep 2003     Yaron Y. Goland, 27 Aug 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)     Francisco Curbera, 17 Sep 2004     Proposed resolution (Dieter Koenig1, 17 Sep 2004)     Yaron Y. Goland, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Assaf Arkin, 18 Sep 2004     Dieter Koenig1, 19 Sep 2004     Satish Thatte, 21 Sep 2004
Changes: 18 Aug 2003 - new issue;    19 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Links;    21 Aug 2003 - fields: Links;    23 Aug 2003 - fields: Links;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    28 Aug 2003 - fields: Links;    30 Aug 2003 - fields: Links;    3 Sep 2003 - fields: Links;    4 Sep 2003 - fields: Links;    8 Sep 2003 - fields: Links;    29 Sep 2003 - fields: Links;    30 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Links;    25 Mar 2004 - fields: Title, Original title;    27 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    17 Sep 2004 - fields: Links;    18 Sep 2004 - fields: Links, Status, Proposed resolution;    20 Sep 2004 - fields: Links;    21 Sep 2004 - fields: Links;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution, In spec

Issue 53: Include Business Transaction Management (BTM) constructs

In our view BTP Cohesions, WS-T Business Activity, and WS-TXM Long-Running Actions are the most relevant aspects of these specifications for WS-BPEL. These aspects overlap to a very high degree, each effectively utilizing a two-phase (promise/decide) outcome protocol. (We should emphasize that there has been little time to analyze or assimilate WS-TXM, so this is a provisional conclusion with respect to that specification).

WS-BPEL should be equipped with the ability to create and terminate business transactions, and to define process participation in such transactions, in a way which is compatible with the intersection of these three capabilities. This will minimize dependence on future standardization efforts in the BTM area.
Original title: Should include Business Transaction Management (BTM) programming constructs compatible with WS-T, BTP and WS-TXM
Revisitable: Yes
Submitter's proposal: Syntax should be added to WS-BPEL to permit

1. Business transaction creation, manifested by the creation of a business transaction context variable.

2. Business transaction context reception and transmission (propagation) via invoke/receive/reply, allowing sub-transaction or pass-through behaviour.

3. Process involvement in business transactions as participants, which can handle positive and negative transaction finalization messages (by means of confirm and cancel handlers).

4. Two-phase termination of business transactions by selection of participants to be prepared, to be cancelled and to be confirmed.

The WS-Coordination specification (proprietary consortium, August 2002) is able to support context passing for multiple coordination protocols, and its use will support the goal of compatibility with WS-T, BTP and WS-TXM.
Resolution: Proposed in Peter Furniss, 31 Mar 2004, decided by Web ballot (ended 28 Apr 2004) , after straw poll at Walldorf ftf

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003     Monica Martin, 27 Aug 2003     Alastair Green, 27 Aug 2003     Issue A in Choreology BTM submission (document details)     David RR Webber, 27 Aug 2003     Monica Martin, 27 Aug 2003     Peter Furniss, 28 Aug 2003     David RR Webber, 28 Aug 2003     Mark Little, 1 Sep 2003     Mark Little, 1 Sep 2003     Mark Little, 1 Sep 2003     David RR Webber, 1 Sep 2003     David RR Webber, 1 Sep 2003     David RR Webber, 1 Sep 2003     Mark Little, 1 Sep 2003     Mark Little, 1 Sep 2003     David RR Webber, 2 Sep 2003     Monica Martin, 1 Sep 2003     Revised submission (document details)     Monica Martin, 14 Sep 2003     Peter Furniss, 13 Oct 2003     Harvey Reed, 13 Oct 2003     Satish Thatte, 13 Oct 2003     Harvey Reed, 13 Oct 2003     Yaron Goland, 20 Oct 2003     Haugen Robert, 24 Oct 2003     Post-Melbourne discussion on coordination questions is under issue 30 issue 30     Alastair J. Green, 7 Jan 2004     Satish Thatte, 7 Jan 2004     Haugen Robert, 8 Jan 2004     Yaron Goland, 8 Jan 2004     Haugen Robert, 9 Jan 2004     Dieter Roller, 9 Jan 2004     Peter Furniss, 9 Jan 2004     Satish Thatte, 9 Jan 2004     Satish Thatte, 9 Jan 2004     Haugen Robert, 9 Jan 2004     Satish Thatte, 10 Jan 2004     Diane Jordan, 12 Jan 2004     Haugen Robert, 12 Jan 2004     Yaron Goland, 12 Jan 2004     Haugen Robert, 12 Jan 2004     Yaron Goland, 13 Jan 2004     Haugen Robert, 13 Jan 2004     Yaron Goland, 20 Jan 2004     Tony Fletcher, 20 Jan 2004     Danny van der Rijn, 20 Jan 2004     LI Yanming / FTR&D / US, 20 Jan 2004     Alastair J. Green, 20 Jan 2004     Tony Fletcher, 23 Jan 2004     Satish's presentation at Melbourne, FL (document details)     Bob Haugen's presentation at Melbourne, FL (document details)     Peter Furniss, 29 Mar 2004     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (document details)     Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    28 Aug 2003 - fields: Links;    3 Sep 2003 - fields: Links;    9 Sep 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    13 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    24 Oct 2003 - fields: Links;    9 Dec 2003 - fields: Links;    7 Jan 2004 - fields: Links;    8 Jan 2004 - fields: Links;    9 Jan 2004 - fields: Links;    12 Jan 2004 - fields: Links;    13 Jan 2004 - fields: Links;    14 Jan 2004 - fields: Links;    20 Jan 2004 - fields: Links;    21 Jan 2004 - fields: Links;    23 Jan 2004 - fields: Links;    15 Mar 2004 - fields: Links;    25 Mar 2004 - fields: Title, Original title;    29 Mar 2004 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 54: Construct to hold Business transaction contexts

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003     Issue B in Choreology BTM submission (document details)     Mark Little, 1 Sep 2003     David RR Webber, 1 Sep 2003     Tony Fletcher, 1 Sep 2003     Mark Little, 1 Sep 2003     Monica Martin, 14 Sep 2003     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (with issue 53) (document details)     Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    3 Sep 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 55: Business transaction propagation

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003     Issue C in Choreology BTM submission (document details)     Monica Martin, 14 Sep 2003     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (with issue 53) (document details)     Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 56: Business transaction creation

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003     Issue D in Choreology BTM submission (document details)     Monica Martin, 14 Sep 2003     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (with issue 53) (document details)     Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 57: Business transaction termination

Remove appendix C and all references to particular transaction and coordination protocols.
Close these issues (30, 53-59) without other change to the spec.
Mark the issues as "revisitable" - to be reconsidered in future work on BPEL.
Links: Announcement, 26 Aug 2003     Issue E in Choreology BTM submission (document details)     Monica Martin, 14 Sep 2003     Proposed resolution (Peter Furniss, 31 Mar 2004)     Peter Furniss, 31 Mar 2004     Discussed at Walldorf f-t-f (with issue 53) (document details)     Web ballot (ended 28 Apr 2004)
Changes: 26 Aug 2003 - new issue;    26 Aug 2003 - fields: Links;    27 Aug 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Vote announcement, Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, Vote announcement, Links;    20 Jun 2004 - fields: In spec

Issue 58: Selective termination of business transaction participants