WS BPEL issues list

This file last updated 0:50 6 Jan 2005 (UTC)

This is the issues list for the OASIS Web Services Business Process Execution Language Technical Committee. The issues list is posted as a TC document to the OASIS WSBPEL TC pages on a regular basis (if it has changed). The current edition, as a TC document, is the most recent version of the document wsbpel_issues_list.html in the "Issues" folder of the WSBPEL TC document list - the uri for this document includes the document number generated by the upload process. The list editor's working copy, which will always at least as recent as the formal upload and will usually include later updates, is available at this constant URI.

• Table of issues with resolution proposed or voting
• Table of potential issues submitted to but not yet accepted by the TC
• Table of issues changed or added recently
• Table of unresolved issues sorted by category (An issue may have more than one category assigned)
• Table of unresolved issues with no identified traffic since a particular date
• Table of resolved issues that require changes to the spec that await inclusion in an editors' draft
• 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 are defined in the issues process document, and the procedure for issues submitted after 15 August 2004. Potential new issues should be submitted as an email to the issue list editor (peter.furniss@choreology.com), with a subject line of "New issue - <proposed title>. If this email follows the pattern described in the issues process document, appendices 5 and 6, it will be helpful. The new issue will be announced on the main wsbpel TC list with a status of "received". In accordance with procedure for issues submitted after 15 August 2004 the TC will decide whether to accept the issue for consideration (when the status will become "open") or not. If messages discussing an issue (including whether the issue should be accepted) have subject lines that begin Issue - <issue-id> - , or are replies to such, the archived copy of that message on the wsbpel list should be picked up by the software that revises this list and added to the Links section of the issue.

Issues with resolution proposed or voting

Issues changed or added since 28 Dec 2004

Open issues by category

Open issues with no identified traffic since 22 Sep 2004

Resolved issues awaiting editing into spec

All issues, in order

The colour of the issue title is determined by the status: red=open (42 issues), maroon=resolution proposed (16 issues), green=resolved (125 issues). 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@ORACLE.COM, 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

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

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

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 spec.
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?
Proposed resolution: Yaron Y. Goland, 17 Sep 2004
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)
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

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

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.

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>

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.]
Changes: 5 Jan 2005 - new issue

Issue 12: XML types and WS Interactions

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

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

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
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
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

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.
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.
Vote announcement: Web ballot (ends 28 Apr 2004)
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)
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)
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

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

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

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 F 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 59: BPEL process as business transaction participant

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 G 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 60: process category

<process  name="ncname" targetNamespace="uri"
   queryLanguage="anyURI"?
   .
   .
   category="ncname"/>

Close with no change to the specification.
Rationale: The process category (and the process priority) belong to a set of attributes that are independent of the process model and rather subject of the process deployment. Having both covered by WS-Policy (from my point of view a reasonable direction) would also increase the reusability of a process model, as it could be deployed multiple times with different category (and priority, see also the proposed resolution of issue 61) attributes.
Links: Sid Askary, 4 Sep 2003     Ron Ten-Hove, 4 Sep 2003     Satish Thatte, 4 Sep 2003     Ron Ten-Hove, 4 Sep 2003     Edwin Khodabakchian, 4 Sep 2003     Satish Thatte, 4 Sep 2003     Satish Thatte, 4 Sep 2003     Sid Askary, 4 Sep 2003     Ron Ten-Hove, 4 Sep 2003     Ron Ten-Hove, 4 Sep 2003     Edwin Khodabakchian, 4 Sep 2003     Ron Ten-Hove, 5 Sep 2003     Assaf Arkin, 5 Sep 2003     Edwin Khodabakchian, 5 Sep 2003     Ron Ten-Hove, 5 Sep 2003     Announcement, 8 Sep 2003     Proposed resolution (Dieter Koenig1, 3 Feb 2004)
Changes: 8 Sep 2003 - new issue;    8 Sep 2003 - fields: Links;    9 Sep 2003 - fields: Links;    3 Feb 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 61: process priority

a)

<process  name="ncname" targetNamespace="uri"
	queryLanguage="anyURI"?
	.
	.
	prioritize="yes|no"?/>

<priority name="ncname"
	priorityNumber="anynumber"
	PriorityNumberBase="anynumber"/>

NOTE: PriorityNumberBase reflects the devisor for PriorityNumber. Alternatively, one could replace the two by a single floating-point fraction.
Submitter: Sid Askary
Resolution: Proposed in Dieter Koenig1, 3 Feb 2004, decided 4 February 2004 con call

Close with no change to the specification.
Rationale: The process priority (and the process category) belong to a set of attributes that are independent of the process model and rather subject of the process deployment. Having both covered by WS-Policy (from my point of view a reasonable direction) would also increase the reusability of a process model, as it could be deployed multiple times with different priority (and category, see also the proposed resolution of issue 60) attributes.
Links: Sid Askary, 4 Sep 2003     Danny van der Rijn, 4 Sep 2003     Edwin Khodabakchian, 4 Sep 2003     Harvey Reed, 4 Sep 2003     Rajesh Pradhan, 4 Sep 2003     Sid Askary, 4 Sep 2003     Satish Thatte, 4 Sep 2003     Monica Martin, 4 Sep 2003     Ron Ten-Hove, 4 Sep 2003     Sid Askary, 4 Sep 2003     Ron Ten-Hove, 5 Sep 2003     Assaf Arkin, 5 Sep 2003     Monica Martin, 5 Sep 2003     Announcement, 8 Sep 2003     Proposed resolution (Dieter Koenig1, 3 Feb 2004)
Changes: 8 Sep 2003 - new issue;    8 Sep 2003 - fields: Links;    9 Sep 2003 - fields: Links;    3 Feb 2004 - fields: Links, Status, Proposed resolution;    11 Feb 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 62: Event handlers and Serializable Scopes

Let's assume a scope S, an event handler E associated with S, a scope S-S that is part of S, and a scope S-E that is part of E. Then the following rules apply

1. If S is marked variableAccessSerializable="yes", then neither scope S-S nor scope S-E can be marked with variableAccessSerializable="yes".

2. If scope S-S is marked variableAccessSerializable="yes", scope S-E can also be marked variableAccessSerializable="yes"

If a serializable scope has an event handler associated with it, no enclosed scope nor a scope in the body of the event handler can be serializable. If a non-serializable scope has an event handler associated with it, an enclosed scope as well as a scope in the body of the event handler can be serializable.

Equivalently: Let's assume a scope S, an event handler E associated with S, a scope S-S that is part of S, and a scope S-E that is part of E. Then the following rules apply

1. If S is marked variableAccessSerializable="yes", then neither scope S-S nor scope S-E can be marked with variableAccessSerializable ="yes".
2. If scope S is marked variableAccessSerializable="no", scope S-E and scope S-S can be marked variableAccessSerializable="yes"

Issue 63: Support of Array

I'm not proposing to define a new data type system for BPEL. We should leverage what is already in XML schema. Although in the XML schema there is a construct to declare repetitive occurrence of element structure, it is designed for describing the XML document being exchanged ? There is a difference between "there are some repetitive elements within a document" and "there are multiple documents".

Therefore, I propose that we need to support "Array"

For example, if a seller is receiving multiple POMessage from multiple buyers, (assuming the complex type of POMessage is already defined), the BPEL will look like this ..

<process>
   <variables>
     <array name="poArray" type="POMessage"/>
   </variables>


   <sequence>
     <iterate array="poArray" count="10">
       <receive partner="buyer" ... array="poArray"/>
     </iterate>
....
   </sequence>
</process>

Issue 64: Explicit declaration of process instantiation

However, since the spec requires the first basic activity in the process must be a <receive createInstance="yes"/>, the actual intention may try to make the process instance distinct rather than homogeneous.

The current mechanism has the following challenges ...

1. We need to define additional constraints (such as it must be the first activity ... etc.) which complicates the model.
2. Locating the "first activity" is not easy. What if the the first activity is a <sequence> which contains another <sequence>, the first basic activity maybe nested multiple levels down. What if the first activity is a <flow> which has multiple starting activities (some are basic activities and some are nested <flows>).

To treat every process instance distinct, I'm suggesting to use a more explicit way to capture the initialization of process instances, which includes

1. The mechanism to instantiate a new process instance
2. What variables will be initiated

<process>
   ....
   <sequence>
   ....
     <receive partner="buyer" portType="p1" operation="submitOrder" 
variable="var1" createInstance="yes"/>
   ....
     <receive ..../>
   <sequence>
</process>

<process>
...
   <triggeredBy>
     <receive partner="buyer" portType="p1" variable="var1" 
operation="submitOrder"/>
   </triggeredBy>
...
   <sequence>
   ....
     <receive ..../>
   <sequence>
</process>

Please note the following difference ...

1. <triggeredBy> is defined outside the root activity, while <receive> is defined inside the root process activity, maybe even multiple level of nesting down. There is no need to locate the first activity in the <triggerBy> case because it is explicitly defined.
2. <triggeredBy> is using a different element tag which makes the initialization step more explicit.
3. The subElement of <triggeredBy> is extensible, so we can introduce new ways to instantiate process instances. At this moment, only a <receive> can be nested inside the <triggerBy>.

Closed with no change
Links: Ricky Ho, 13 Sep 2003     Dieter Roller, 13 Sep 2003     Ricky Ho, 13 Sep 2003     Ricky Ho, 13 Sep 2003     Ron Ten-Hove, 15 Sep 2003     Announcement, 15 Sep 2003     Ricky Ho, 15 Sep 2003     Eckenfels. Bernd, 16 Sep 2003     Ricky Ho, 16 Sep 2003     Dieter Roller, 17 Sep 2003     David RR Webber, 17 Sep 2003     Ricky Ho, 17 Sep 2003     Proposed resolution (Yaron Y. Goland, 9 Oct 2004)
Changes: 15 Sep 2003 - new issue;    15 Sep 2003 - fields: Links;    16 Sep 2003 - fields: Links;    17 Sep 2003 - fields: Links;    11 Oct 2004 - fields: Links, Status, Proposed resolution;    14 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec

Issue 65: Multiple partners of a partner type

Lets look at an auction scenario ...

1. Seller announce something to see (for simplicity, let say this is done outside the process)
2. Seller start the process. There can be many "potential buyers" sending bids to the seller. Seller just collect them.
3. After the bidding deadline, the seller pick the bid with highest value to be the "buyer"
4. Seller send a confirmation to the selected buyer

There are three roles. "Seller", "Bidder" and "Buyer". How many <partner> do I have in my BPEL ?
Resolution: Proposed verbally by Satish Thatte and decided at San Francisco f-t-f

Close with no change to spec.
Rationale: Partly a misunderstanding notion of partner, partly covered by other issues, including issue 4.
Links: Announcement, 15 Sep 2003
Changes: 15 Sep 2003 - new issue;    15 Sep 2003 - fields: Links;    22 Jun 2004 - fields: In spec, Resolution, Rationale, Status

Issue 66: Zero or multiple matches of correlation set

1) When an incoming message matches multiple process instances, which one will get the message ?

e.g. ProcessA is executing

    <receive portType="PT1" operation="oper" ...   	createInstance="yes"/>

ProcessB is executing

    <receive portType="PT1" operation="oper" ...  	createInstance="yes"/>

    <receive portType="PT1" operation="oper" ...   createInstance="no"/>

Lets say someone invoke "PT1/oper" and it matches the correlation set of the processC instance. Who gets the message ?

2) When an incoming message matches zero process instances, does the sender get a fault ? or the message will be queued until a matching process instances gets it later

e.g. A sender invoke "PT2/oper2" but no process is listening in that.
Resolution: Proposed verbally by Paco Cabrera and decided at San Francisco f-t-f

No normative change, but the editors' group will add a note for implementors pointing out that there are possible implementation alternatives and that users may need to be aware of these.
Links: Announcement, 20 Sep 2003     Yaron Goland, 23 Sep 2003     Ricky Ho, 23 Sep 2003     Danny van der Rijn, 23 Sep 2003     Prasad Yendluri, 24 Sep 2003     Satish Thatte, 24 Sep 2003     Danny van der Rijn, 24 Sep 2003     Satish Thatte, 24 Sep 2003     Ron Ten-Hove, 24 Sep 2003     Ron Ten-Hove, 24 Sep 2003     Francisco Curbera, 24 Sep 2003     Ugo Corda, 24 Sep 2003     Satish Thatte, 24 Sep 2003     Satish Thatte, 24 Sep 2003     Danny van der Rijn, 24 Sep 2003     Ron Ten-Hove, 24 Sep 2003     Assaf Arkin, 25 Sep 2003     Francisco Curbera, 25 Sep 2003     Satish Thatte, 26 Sep 2003     Ron Ten-Hove, 26 Sep 2003     Ron Ten-Hove, 26 Sep 2003     Tony Fletcher, 29 Sep 2003     Assaf Arkin, 1 Oct 2003     Discussed at San Francisco ftf
Changes: 19 Sep 2003 - new issue;    22 Sep 2003 - fields: Links;    24 Sep 2003 - fields: Links;    25 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    29 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Links;    22 Jun 2004 - fields: Links, In spec, Resolution, Status

Issue 67: Clarify semantics of serializable scopes

Add the following sentences to section to Section 13.6 following paragraph 2.

Note that serialization of variable access cannot lead to internal deadlock in a BPEL process instance. The reason being that, conceptually, a serializable scope is not started until it can gain sufficiently exclusive access to all the non-local variables it needs.

Issue 68: catch syntax broken

This is because we make

1. The faultName optional, and
2. the faultVariable is ".. deemed to be declared by virtue of being used as the value of this attribute and is local to the fault handler .."

Change the syntax of faultHandlers to the following

<faultHandlers>?
    <!-- there must be at least one fault handler or default -->
    <catch faultName="qname"? faultVariable="ncname"?
                              faultMessageType="qname"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
</faultHandlers>

And in addition, add the following sentences immediately following the syntax.

Note that the faultName, faultVariable and faultMessageType attributes are all optional. However, the faultVariable and faultMessageType declarations go together, i.e., they must either both be present or both absent. This is to ensure that the type of the faultVariable is well specified even when the faultName is omitted. Moreover, the faultName and faultVariable attributes cannot both be absent.

Issue 69: When to clear link status

Link target and/or source activities can be run more than once if the process contains a loop (i.e. while acitivity).

When to clear the link status in such cases is not defined in the current specification.
Submitter's Proposal: Possible resolutions are to specify that the link status is cleared:

1. Only at the very beginning of the process / event handler thread; OR
2. Every time the scope that directly encloses the link owner flow activity starts; OR
3. Every time the link owner flow activity starts.

I would propose C. In the following example, A1 and A2 are cleared every time flow A is started and B1 and B2 are cleared every time flow B is started.

<while ...>
  <flow name="base">
    <flow name="A">
      <links>
        <link name="A1"/>
        <link name="A2"/>
      </links>


      ... activities ...
    </flow>
    <while ...>
      <flow name="B">
        <links>
          <link name="B1"/>
          <link name="B2"/>
        </links>


        ... activities ...
      </flow>
    </while>
  </flow>
</while>

Updated proposal for 69: - new subject for script magic - added Satish's clarification of def in 12.5 - replaced "defined" with "declared" (i.e. links are declared)

New text shown in italics, old text as strikeout

Section 12.5: Flow

Change the following text:

In general, a link is said to cross the boundary of a syntactic construct if the source activity for the link is nested within the construct but the target activity is not, or vice versa, if the target activity for the link is nested within the construct but the source activity is not. A link is said to cross the boundary of a syntactic construct if the source or target activity for the link is nested within the construct while the link is declared outside the construct. Note that it is possible for a link to cross the boundary of a syntactic construct even in those cases where both the source and the target activities are nested within the same construct: so long as the link is /declared/ outside that construct.

Insert the following text:

The precise semantics of link status evaluation are as follows: The link status is a tri-state flag associated with each declared link. This flag may be in the following three states: "positive", "negative", or "unset". Each time a certain flow activity is activated, the link status of all the links declared in that activity is "unset", that is the lifetime of the status of a link is exactly the lifetime of the flow activity within which it is declared. When activity A completes, the following steps are performed to determine the effect of the synchronization links on other activities:

The above changes imply option C (if you all remember the options). The second part is essentially Satish's earlier proposal in the context of the current language, while the first part addresses the problem brought up by Yaron in the conference call relating to while loops that use links declared outside the while loop. The major consequence of the above changes is that the following is no longer permitted:

<flow name="f1">
  <link name="l1">
  <while>
    <flow name="f2">
      <empty>
        <source linkName="l1"/>
      </empty>
      <empty>
        <target linkName="l1"/>
      </empty>
    </flow>
  </while>
</flow>

The link "l1" will now need to be declared in "f2".

The issue of whether links are belong in scopes as opposed to flows will be made a separate issue.
Links: Announcement, 27 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Proposed resolution (Satish Thatte, 15 Jan 2004)     Maciej Szefler, 22 Jan 2004     Satish Thatte, 26 Jan 2004     Yaron Goland, 26 Jan 2004     Satish Thatte, 26 Jan 2004     Maciej Szefler, 27 Jan 2004     Discussed at 21 January 2004, deferred for further discussion     Satish Thatte, 28 Jan 2004     Maciej Szefler, 28 Jan 2004     Satish Thatte, 28 Jan 2004     Maciej Szefler, 11 Feb 2004     Satish Thatte, 13 Feb 2004     Proposed resolution (Maciej Szefler, 13 Feb 2004)     Eckenfels. Bernd, 13 Feb 2004     Maciej Szefler, 13 Feb 2004
Changes: 27 Sep 2003 - new issue;    27 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links, Status, Proposed resolution;    22 Jan 2004 - fields: Links;    26 Jan 2004 - fields: Links;    27 Jan 2004 - fields: Links;    28 Jan 2004 - fields: Links;    29 Jan 2004 - fields: Links;    13 Feb 2004 - fields: Links;    16 Feb 2004 - fields: Links, Status, Proposed resolution;    18 Feb 2004 - fields: Links, Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 70: suppressJoinFailure default value

A value of "yes" for [suppressJoinFailure] has the effect of suppressing the bpws:joinFailure fault for the activity and all nested activities, except where the effect is overridden by using the suppressJoinFailure attribute with a value of "no" in a nested activity.

By having the schema specify a default value for suppressJoinFailure for each activity element, nested activities always reset the value of suppressJoinFailure instead of inheriting it.
Submitter's proposal: If I am reading this wrong, perhaps someone can clarify. Otherwise, I propose, in the schema's tActivity declaration, replacing this:

<attribute name="suppressJoinFailure" type="bpws:tBoolean" default="no"/>

<attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional"/>

Make the following changes to the spec:

1. remove / change the wrong description default value of suppressJoinFailure attribute of an activity from section 6.2:

   Existing Text:

   where the default values are as follows:

   • name. No default value (that is, unnamed)
   • joinCondition. The logical OR of the liveness status of all links that are targeted at this activity
   • suppressJoinFailure. No

   New Text:

   where the default values are as follows:

   • name. No default value (that is, unnamed)
   • joinCondition. The logical OR of the liveness status of all links that are targeted at this activity
   • suppressJoinFailure. In case the suppressJoinFailure attribute is omitted for an activity, it is inherited from its closest enclosing activity.

2. To remove / change the wrong description from section 11.1 "Standard Attributes for Each Activity": Existing description:

   "The default value of suppressJoinFailure is no."

   New description:

   "In case the suppressJoinFailure attribute is omitted for an activity, it is inherited from its closest enclosing activity"

3. in Appendix B for Standard Attribute, specify the following in the "Defaults" column for suppressJoinFailure:

   "no for process element. This attribute is optional for activities other than process. When not present for such an activity, it inherits its value from its closest enclosing activity."

4. To change the description of Section 12.5.2. "Dead-Path-Elimination (DPE)":

   Existing description:

   "The default value of the suppressJoinFailure attribute is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.

   New description:

   "The default value of the suppressJoinFailure attribute of process element is "no". This is to avoid unexpected behavior in simple use cases where complex graphs are not involved and links without transition conditions are used for synchronization.

5. change the BPEL schema (in appendix D and its OASIS location) to replace the current tActivity declaration:

   <attribute name="suppressJoinFailure" type="bpws:tBoolean" default="no"/>

   with this:

   <attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional">

In addition, give the editors action to double check the spec and make editorial changes as they see appropriate to reflect resolution for this issue.
Links: Jim Clune, 26 Sep 2003     Francisco Curbera, 26 Sep 2003     Announcement, 30 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Proposed resolution (Kevin Liu, 27 Jan 2004)     Alex Yiu, 4 Feb 2004     Kevin Liu, 4 Feb 2004     Satish Thatte, 4 Feb 2004     Proposed resolution (Kevin Liu, 4 Feb 2004)
Changes: 30 Sep 2003 - new issue;    30 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links;    27 Jan 2004 - fields: Links, Status, Proposed resolution;    4 Feb 2004 - fields: Links, Status, Proposed resolution;    18 Feb 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 71: Removal of wsdl:message

Closed with no change (c.f resolution of issue 15 : WSDL MEPs )
Links: split from issue 47     Announcement, 1 Oct 2003     Proposed resolution (Yaron Y. Goland, 5 Oct 2004)     Satish Thatte, 6 Oct 2004     Kevin Liu, 9 Oct 2004
Changes: 1 Oct 2003 - new issue;    1 Oct 2003 - fields: Links;    6 Oct 2004 - fields: Links, Status, Proposed resolution;    11 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec

Issue 72: What to do with WS-I BP1.0?

1. Would BP 1.0 be restricting BPEL to the point that some of BPEL's functionality would not be available?
2. Would the fact that BP 1.0 only addresses the SOAP/HTTP binding imply that also BPEL should be limited to that type of binding?
3. Should a BPEL process be offered as a Web service that is BP 1.0 compliant?
4. Would it be fair to limit BPEL use to interacting with BP 1.0 compliant Web services only?

Given that the scope of BP is confined to the specifications it references, and that BPEL is of wider application:

1. In developing the BPEL language, where reference is made to specifications that are in BP 1.0 scope, the BP 1.0 requirements will normally be followed.

2. Where use-cases and use-case artifacts are in BP 1.0 scope (i.e. using referenced specifications) they will be BP 1.0 compliant, if possible.

3. All BPEL implementations SHOULD be configurable such that they can participate in BP1.0 compliant interactions. A BPEL implementation MAY allow the BP 1.0 configuration to be disabled, even for scenarios encompassed by BP 1.0.

Issue 73: "wsdl:fault" element not allowed with one-way operation

<portType name="BuyerPT"> 
    <operation name="AsyncPurchaseResponse"> 
        <input message="smsg:POResponse"/> 
        <fault name="tns:RejectPO" message="smsg:POReject"/> 
    </operation> 
    <operation name="AsyncPurchaseReject"> 
        <input message="smsg:POReject"/> 
    </operation> 
</portType> 

<portType name="BuyerPT"> 
    <operation name="AsyncPurchaseResponse"> 
        <input message="smsg:POResponse"/> 
    </operation> 
    <operation name="AsyncPurchaseReject"> 
        <input message="smsg:POReject"/> 
    </operation> 
</portType> 

Accept the "submitter's proposal".
Links: Announcement, 6 Oct 2003     Proposed resolution (Ugo Corda, 8 Jan 2004)
Changes: 6 Oct 2003 - new issue;    6 Oct 2003 - fields: Links;    8 Jan 2004 - fields: Links, Status, Proposed resolution;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 74: Ambiguity in join condition definition

Every activity that is the target of a link has an implicit or explicit joinCondition attribute associated with it; an activity that is not target of a link has no joinCondition attribute associated with it.

A) remove "joinCondition" from the set of Standard attributes for each activity

• remove mentioning and description of joinCondition from 11.1 on p. 53
• remove mentioning of joinCondition="bool-expre"? from the formal description in 11.1
• remove paragraph right above 11.2 (which was the actual text which triggered this issue)

- change formal syntax definition: