WS BPEL public review issues list

This file last updated 9:27 21 Nov 2006 (UTC)

This is the issues list for the public review of the WS-BPEL 2.0 specification, maintained on behalf of the OASIS Web Services Business Process Execution Language Technical Committee. This review 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 Current WS-BPEL Review Issues List 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 (which can thus be used as the base for the anchors to individual issue entries of the form "IssueRNN").

Comments received on the public comment list will generally be made issues on this list - the Origin field is used to identify these issues. Members of the TC can send issue proposals to the chairs, copying the issue list editor peter@furniss.co.uk. (The Submitter field identifies the TC member submitting the issue).

The issues list used in progressing the WS-BPEL spec to public review is now closed.

• Table of accepted, but unresolved issues, including issues with proposed resolutions
• Table of potential issues submitted to but not yet accepted by the TC
• Table of issues changed or added recently
• Table of all issues, ordered by issueID
  
  
• Detailed list of issues. The issues in this list have anchors of the form "IssueR1", "IssueR22".

There are no unresolved issues (open or resolution proposed)

There are no proposed issues

There are no resolved issues awaiting editing into spec

Issues changed or added since 12 Nov 2006

Issues arising from public comment list

All issues, in order

The colour of the issue title is determined by the status: green=resolved (43 issues). (Those numbers count sub-issues as separate.) According to the TC issue procedures (issues process document), the formal status values are "open" and "resolved". The "In spec" entry in resolved issues indicates that the required editting has been checked into the repository version of the text, on or before the date given. Note that such changes are NOT reflected in the fixed public review text.

Issue R1: keepSrcElement behavior for virtual <assign>'s

The recent work on Issue 280 got me thinking about keepSrcElement as it relates to the virtual assigns used to describe the behavior of <fromParts>, <toParts>, and receiving into or transmitting an element variable.

Section 10.3 describes invoking with an element variable as equivalent to declaring an anonymous temporary WSDL message variable and using the element’s value to “set the value of the part”. It is reasonable to assume that the spec here is referencing the <assign> rules but it is not explicit.

Section 10.3.1 describes invoking with <toParts> as working as a single virtual <assign> using the same rules as the real <assign>. There is a normative MUST in this section which precludes the possibility of applying the keepSrcElement behavior since it is off by default on the real <copy>.

The lack of the keepSrcElement behavior for these virtual <assign>’s means that the root element of the variable being sent or received may change when it is copied to or from the WSDL message. This is definitely the behavior with <fromPart> and <toPart> and could be interpreted as being the behavior of the element variants of web service activities.
Submitter's proposal: I’d like to see the keepSrcElement behavior enabled for these virtual <assign>’s. Dieter has suggested adding “keepSrcElement” to the <fromPart> and <toPart> elements to control this behavior. I’m agreeable to this but we still need to handle the element style invokes and receives. If we want the behavior to be configurable as opposed to always enabled then perhaps we could add the keepSrcElement attribute to the web service activities as well.
Resolution: Proposed in Mark Ford, 25 Oct 2006, agreed with amendment 1 Nov 2006

Final resolution is in Mark Ford, 1 Nov 2006
Links: Announcement, 7 Aug 2006     Mark Ford, 6 Oct 2006     Proposed resolution (Mark Ford, 25 Oct 2006)     Danny van der Rijn, 25 Oct 2006     Mark Ford, 25 Oct 2006     Danny van der Rijn, 25 Oct 2006     Mark Ford, 25 Oct 2006     Mark Ford, 1 Nov 2006
Changes: 4 Aug 2006 - new issue;    16 Aug 2006 - fields: Links;    10 Sep 2006 - fields: Status, Note;    20 Sep 2006 - fields: Status;    6 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Links, Status, Proposed resolution;    30 Oct 2006 - fields: Links;    2 Nov 2006 - fields: Links, Status, Proposed resolution, Resolution, Change status;    6 Nov 2006 - fields: In spec

Issue R2: Zero or Negative Duration Values

The WS-BPEL 2.0 specification (public review draft) is silent w.r.t. the behavior if a specified duration has a zero or negative value.
Submitter's proposal: I propose that language is added which specifies that

1. wait and onAlarm are immediately executed if a specified duration has a zero or negative value
2. zero or negative values are disallowed for repeatEvery

10.7. Delayed Execution - Wait Add to the end of the first paragraph: "If a specified duration value is zero or negative then the wait activity completes immediately."

11.5. Selective Event Processing – Pick Add to the end of the second bullet in the second paragraph: "If a specified duration value is zero or negative then <onAlarm> event occurs immediately. Again, the handling of race conditions is implementation dependent."

12.7.2. Alarm Events Add after the fourth sentence in the first paragraph: "If the specified duration value is zero or negative then the <onAlarm> event is executed immediately.". Add to the end of the first paragraph: "If the specified duration value is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown."

12.7.4.1. Alarm Events Add to the end of the first paragraph: "If the specified duration value is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown."

Text as in Dieter Koenig1, 26 Sep 2006
Links: Announcement, 10 Sep 2006     Proposed resolution (Dieter Koenig1, 21 Sep 2006)     Proposed resolution (Dieter Koenig1, 26 Sep 2006)
Changes: 10 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    21 Sep 2006 - fields: Links, Status, Proposed resolution;    26 Sep 2006 - fields: Links, Status, Proposed resolution;    4 Oct 2006 - fields: Change status, Status, Proposed resolution, Resolution;    25 Oct 2006 - fields: In spec

Issue R3: Appendix H - earlier members need to be added

Among others, the following original BPEL4WS 1.1 authors are not listed - (checks need to be made whether they actually joined the TC)

• Tony Andrews, Microsoft
• Hitesh Dholakia, Siebel Systems
• Yaron Goland, BEA
• Johannes Klein, Microsoft
• Frank Leymann, IBM
• Dieter Roller, IBM
• Doug Smith, Siebel Systems
• Sanjiva Weerawarana, IBM

See proposal in Diane Jordan, 31 Oct 2006
Links: Announcement, 10 Sep 2006     Proposed resolution (Diane Jordan, 31 Oct 2006)     Danny van der Rijn, 1 Nov 2006
Changes: 10 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    31 Oct 2006 - fields: Links, Status, Proposed resolution;    2 Nov 2006 - fields: Links, Status, Proposed resolution, Change status, Resolution;    6 Nov 2006 - fields: In spec

Issue R4: missing namespace prefix declaration in Section 15.4.1

Issue R5: Wrong namespace in Section 13.1.2

From the Action Item:

This section has a process snippet that introduces the "abstractProcessProfile" attribute. The xmlns for the process element is http://docs.oasis-open.org/wsbpel/2.0/process/executable but it should be http://docs.oasis-open.org/wsbpel/2.0/process/abstract

Issue R6: TOC is messed up in PDF version

The highest page number that the PDF TOC refers to is '3'

The TOC should have been regenerated prior to creating the PDF.
Resolution: Decided conf call 20 Sep 2006
Sent to editors for correction

Since the correction only concerns the final production of the alternative forms of the document, no editing is required.
Links: Announcement, 15 Sep 2006
Changes: 15 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Resolution;    21 Sep 2006 - fields: In spec, Resolution;    4 Oct 2006 - fields: Change status

Issue R7: Figure 1 truncated in XHTML

Since the correction only concerns the final production of the alternative forms of the document, no editing is required.
Links: Announcement, 15 Sep 2006
Changes: 15 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Resolution;    21 Sep 2006 - fields: In spec, Resolution;    4 Oct 2006 - fields: Change status

Issue R8: Create separate isolation domain for isolated scope's compensation handler

As the proposal in Alex Yiu, 20 Oct 2006
Links: Announcement, 18 Sep 2006     Alex Yiu, 4 Oct 2006     Mark Ford, 6 Oct 2006     Proposed resolution (Alex Yiu, 10 Oct 2006)     Proposed resolution (Alex Yiu, 18 Oct 2006)     Dieter Koenig1, 18 Oct 2006     Alex Yiu, 20 Oct 2006
Changes: 18 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    4 Oct 2006 - fields: Links;    6 Oct 2006 - fields: Links;    11 Oct 2006 - fields: Links, Status, Proposed resolution;    18 Oct 2006 - fields: Links, Status, Proposed resolution;    21 Oct 2006 - fields: Links;    31 Oct 2006 - fields: Status, In spec, Proposed resolution, Resolution;    2 Nov 2006 - fields: Change status

Issue R9: Remove LED Comment on eventHandlers declaration

<xsd:documentation>
       Child element onAlarm needs to be a LED, because there is another
       onAlarm element defined for the pick activity.
</xsd:documentation> 

This is only interesting to XSD authors, and so probably not for the general audience.
Submitter's proposal: Remove the comment
Resolution: Proposed in Diane Jordan, 4 Oct 2006, agreed conf call 4 Oct 2006

Text as in Diane Jordan, 4 Oct 2006
Links: Announcement, 19 Sep 2006     Danny van der Rijn, 19 Sep 2006     Danny van der Rijn, 20 Sep 2006     Alex Yiu, 20 Sep 2006     Diane Jordan, 4 Oct 2006
Changes: 19 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Links;    4 Oct 2006 - fields: Status, Change status, Resolution, Links;    25 Oct 2006 - fields: In spec

Issue R10: Definition of IMA scope

I would like to request to open a review issue to improve the ease of understanding of the spec. The discussion was under the thread of subject: "A possible issue concerning the definition of IMA scope" started by Ron Ten-Hove.

If the issue is passed, we would just need to refine some cross-referencing of terms and bookmark.
Submitter's proposal:

Besides 10.4.1, another relevant part of IMA and message exchange handling is in section 12.2:

12.2. Message Exchange Handling

When the primary activity and the event handlers of a <scope> complete then all Web service interactions dependent on partner links or message exchanges declared inside of the <scope> need to be completed. An orphaned IMA occurs when an IMA using a partner link or message exchange, declared in the completing <scope> or its descendants, remains open. ....

I would suggest to do a brief update in 10.1.4 from:

Further if an open IMA goes out of scope prior to being closed

Further if an open IMA goes out of scope (known as an orphaned IMA) prior to being closed

(see section 12. Scopes for other details of bpel:missingReply).

(see section 12.2 Message Exchange Handling for other details of bpel:missingReply and orphaned IMA).

Text as in Alex Yiu, 22 Sep 2006
Links: Ron Ten-Hove, 23 Aug 2006     Danny van der Rijn, 23 Aug 2006     Alex Yiu, 23 Aug 2006     Monica J. Martin, 23 Aug 2006     Announcement, 19 Sep 2006     proposed resolution
Changes: 19 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    25 Sep 2006 - fields: Proposed resolution, Status, Links;    4 Oct 2006 - fields: Change status, Status, Proposed resolution, Resolution;    25 Oct 2006 - fields: In spec

Issue R11: Section 12.7 Duplicated (Two Sections)

12.7. Event Handlers 12.7. Isolated Scopes
Proposed resolution: Verify and correct. Also, may need to verify and update other related section reference inconsistencies. Note, this Section 12.7 numbering change may affect at a minimum:

1. Sections subsequent to 12.7 Event Handlers
2. All references through the specification that reference those sections in 1. including any for static analysis where applicable.

Issue R12: Isolated Scopes

The isolated attribute of a scope, when set to "yes", provides control of concurrent access to shared resources: variables, partner links, and control dependency links. Its default value is "no". Such a scope is called an isolated scope.

The isolated attribute of a scope, when set to "yes", provides control of concurrent access to shared resources: variables, partner links, and control dependency links. Such a scope is called an isolated scope. The default value of the isolated attribute is "no".

Issue R13: BPEL partner link assignments

For the purpose of discussion, I'm considering a simple "router" process (R). The one operation exposed by this process includes 2 parts:

1. an amount (xsd:int)
2. the EPR of the requesting process (process REQ)

Based on content in the incoming request, the router chooses a process (process B) to "forward" the request to. Process B is expected to invoke an agreed upon operation on Process REQ, using the EPR information in the message.

There are 2 possible implementations:

1. The router process assigns from the receiving partner link to a variable (or message part) which is then relayed to process B. Process B then performs its activities and assigns this value to the a partner link which it uses to invoke an operation on REQ.
2. REQ is responsible to assign from "myrole" on the partner link facing the router into the a message it eventually sends it.

Based on my reading of the 8/23 draft, both implementations are supported.

The questions for which I have no clear answer are:

1. Is implementation option a) supported ?

   Assuming it is, the spec in silent on IMA activities affecting the partner link for the purpose of assign activities, and the lifetime of the partner link value.

   My expectation would be that once an IMA activity has completed, assigning from the partner link would yield the reply-to EPR.

   Would this also require the partner link variants of the Assign activity to include a messageExchange attribute.

2. Assuming the above is valid, what would the schema type of the variable( or message part) into which the EPR is assigned be? serf:service-reference - in the case of message part, this would cause BPEL specific types to be "leaked" into the abstract WSDL. wsa:endpoint-reference - this would bind the BPEL process to a specific addressing scheme.

   In either case, it would be useful for the spec to be specific about this point (and an example would be great).

3. Section 6.3 ("Endpoint References")states:

   The <sref:service-ref> element is not always exposed to WS-BPEL process definitions. For example, it is not exposed in an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partnerLink-B. On the contrary, it is exposed in an wsbpel-specification-assignment from a messageType or element based variable through expression or from a literal <sref:service-ref>.

   Section 8.4.3 states that the following is not a valid assignment: the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).

   It is not clear if these to sections are contradicting.

   If assignments to/from partner links is allowed (which is explicitly stated in section 8.4), what are the valid combinations?

close with no change. Explanation has been provided to address the questions raised by this comment. TC doesn't see a need for further action.
Links: Announcement, 20 Sep 2006     Dieter Koenig1, 22 Sep 2006     Dieter Koenig1, 25 Sep 2006     James Pasley, 25 Sep 2006     Danny van der Rijn, 25 Sep 2006     Dieter Koenig1, 26 Sep 2006     Diane Jordan, 16 Oct 2006     Diane Jordan, 23 Oct 2006
Changes: 20 Sep 2006 - new issue;    21 Sep 2006 - fields: Links;    22 Sep 2006 - fields: Links;    25 Sep 2006 - fields: Links;    26 Sep 2006 - fields: Links;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, In spec, Resolution, Links

Issue R14: Reference source not found in section 12.4

A fault inside a termination handler MUST NOT be not propagated to the enclosing scope (see section Error! Reference source not found.). Other than that, all of the statements about fault handlers apply to termination handlers as well.

The section link should be fixed. This applies to the HTML and PDF versions. Other versions might be affected too.

There are also broken links in 11.7 and 12.5
Resolution: Proposed and agreed, conf call 4 Oct 2006

Referred to editors for fixing
Links: Announcement, 21 Sep 2006
Changes: 21 Sep 2006 - new issue;    22 Sep 2006 - fields: Links;    4 Oct 2006 - fields: Status, Change status, Resolution;    25 Oct 2006 - fields: In spec

Issue R15: Fix description of abnormal process completion

Thanks to Monica for finding this inconsistency and Alex for providing some edits.
Submitter's proposal:

Change paragraph in Section 5.5 FROM:

A business process instance ends either normally or abnormally. The process ends normally when the main activity of the process completes. The process ends abnormally if either:

• a fault reaches the process scope, regardless of whether it is handled or not (see section 10.10. Immediately Ending a Process – Exit), or
• the process instance is explicitly ended by an exit activity (see section 10.10. Immediately Ending a Process).

TO:

A business process instance ends either normally or abnormally. The process ends normally when the main activity of the process completes. The process ends abnormally if either:

• a process level (explicit or default) fault handler completes or
• the execution of a process level fault handler itself faults (the effect of this particular case is similar to an <exit> activity or
• the process instance is explicitly ended by an exit activity (see section 10.10. Immediately Ending a Process).

As the proposal in Alex Yiu, 20 Oct 2006 with the amendment in Dieter Koenig1, 25 Oct 2006
Links: Alex Yiu, 4 Oct 2006     Alex Yiu, 4 Oct 2006     Danny van der Rijn, 4 Oct 2006     Danny van der Rijn, 4 Oct 2006     Announcement, 4 Oct 2006     Alex Yiu, 20 Oct 2006     Mark Ford, 20 Oct 2006     Monica J. Martin, 20 Oct 2006     Proposed resolution (Alex Yiu, 20 Oct 2006)     Proposed resolution (Dieter Koenig1, 25 Oct 2006)
Changes: 26 Sep 2006 - new issue;    4 Oct 2006 - fields: Status, Links;    6 Oct 2006 - fields: Links;    21 Oct 2006 - fields: Links, Status, Proposed resolution;    30 Oct 2006 - fields: Links, Status, Proposed resolution;    31 Oct 2006 - fields: In spec, Status, Proposed resolution, Resolution;    2 Nov 2006 - fields: Change status

Issue R16: confusing description of Message Exchange Handling

• If a fault handler has completed without any unhandled fault then a check for orphaned IMA’s MUST be made. If any orphaned IMA is detected then a new bpel:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). However, if the fault handler is handling a bpel:missingReply fault and no new IMA's were created and left open by the fault handler, the new fault MUST NOT be generated and thrown. The newly thrown bpel:missingReply fault MUST encompass all orphaned IMA's. When the bpel:missingReply fault is thrown, all the orphaned IMA's are encompassed by the fault and are no longer considered orphaned.

I get lost after the second sentence. What fault is the 3rd sentence referring to? If it MUST NOT be generated and thrown, then what is the point of the 4th sentence?
Resolution: Proposed in Danny van der Rijn, 26 Oct 2006, agreed 1 Nov 2006

See proposal in Danny van der Rijn, 26 Oct 2006
Links: Proposed resolution (Danny van der Rijn, 4 Oct 2006)     Announcement, 4 Oct 2006     Mark Ford, 6 Oct 2006     Danny van der Rijn, 6 Oct 2006     Mark Ford, 6 Oct 2006     Danny van der Rijn, 6 Oct 2006     Proposed resolution (Danny van der Rijn, 26 Oct 2006)
Changes: 26 Sep 2006 - new issue;    4 Oct 2006 - fields: Links, Status, Proposed resolution;    6 Oct 2006 - fields: Links;    31 Oct 2006 - fields: Proposed resolution, Links;    2 Nov 2006 - fields: Status, Proposed resolution, Change status, Resolution;    6 Nov 2006 - fields: In spec

Issue R17: Schema for abstract processes is not valid

<xsd:complexType name="tOnAlarmEvent">
 <xsd:complexContent>
   <xsd:extension base="tExtensibleElements">
     <xsd:sequence>
       <xsd:choice>
         <xsd:sequence>
           <xsd:group ref="forOrUntilGroup" minOccurs="0"/>
           <xsd:element ref="repeatEvery" minOccurs="0"/>
         </xsd:sequence>
         <xsd:element ref="repeatEvery" minOccurs="0"/>
       </xsd:choice>
       <xsd:element ref="scope" minOccurs="0"/>
     </xsd:sequence>
   </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

This is not valid XML schema, because the content model is not deterministic. If in an instance document the first child element is <bpel:repeatEvery> it's not clear which path in the schema applies. Within the choice it can be either be the sequence path (forOrUntilGroup's minOccurs="0" allows that) or the second repeatEvery element reference path.
Submitter's proposal: The schema for abstract processes needs to be changed with the result that the content model is deterministic. I propose to replace the complex type found in the description above with the following complex type:

<xsd:complexType name="tOnAlarmEvent">
 <xsd:complexContent>
   <xsd:extension base="tExtensibleElements">
     <xsd:sequence>
       <xsd:group ref="forOrUntilGroup" minOccurs="0"/>
       <xsd:element ref="repeatEvery" minOccurs="0"/>
       <xsd:element ref="scope" minOccurs="0"/>
     </xsd:sequence>
   </xsd:extension>
 </xsd:complexContent>
</xsd:complexType> 

The copy of the schema in the appendix of the specification needs to be changed accordingly.
Resolution: Decided conf call, 18 Oct 2006

As submitter's proposal
Links: Announcement, 4 Oct 2006
Changes: 4 Oct 2006 - new issue;    6 Oct 2006 - fields: Links;    25 Oct 2006 - fields: In spec, Status, Change status, Resolution

Issue R18: Uniqueness of WSDL Faults

portType pT
    operation op
          input element = "a:b"
          output element = "a:c"
          fault name="fault1" element = "a:fault"
          fault name="fault2" element = "a:fault"

Most WSDL transports (e.g. SOAP) do not tranport fault names on the wire. Usually all that is transmitted is the "a:fault" element, wrapped in some information that does not include the fault name.

Yet 10.3 states that "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding port type and the fault name." We have no way of deriving, in this case, whether we're talking about foo:fault1 or foo:fault2.

Possible resolutions include

• changing the fault catching behavior to not use fault name, but its data type
• disallowing WSDLs that use the same element in more than one fault in an operation. (In the whole WSDL?)
• explicitly specifying rules for inferring fault names. For example, we could say that "a:fault" will always be turned into "foo:fault1" and "foo:fault2" will never be inferred.

Change 10.3, page 86 from

In WSDL it is possible to declare an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL process to infer which fault was intended. In this case, the WS-BPEL process MUST infer the first fault declared for the operation that matches the transmitted data. A result of this requirement is that a process may have different behavior when deployed against different bindings.

In WSDL it is possible to define an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL processor to determine which fault was intended. In this case, the WS-BPEL processor MUST select the fault that:

• Matches the transmitted data and
• Occurs first in lexical order in the operation definition

A result of this requirement is that a process, which uses the <catch> construct based on faultName and deals with such an operation definition, may have different behavior when deployed against different bindings.

and section 3, P. 11 change to

While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility is not feasible.

• Fault naming with its restriction, as discussed later in this document (see section 10.3 Involing Web service operations)

Issue R19: Syntax-fault in example on page 168

<invoke partnerLink="customer"
    operation="shippingNotice"
    inputVariable="shipNotice" />
<correlations>
    <correlation set="shipOrder" pattern="request" /> </correlations> </invoke>

<invoke partnerLink="customer"
    operation="shippingNotice"
    inputVariable="shipNotice">
    <correlations>
        <correlation set="shipOrder" pattern="request" />
    </correlations>
</invoke>

As submitter's proposal
Links: Announcement, 11 Oct 2006
Changes: 11 Oct 2006 - new issue;    12 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R20: Fault handling example in Section 12.5 is incorrect

I also don’t think the text below the example should reference the catch logic via xml-syntax. Change <catch>-logic-A to catch-logic-A since that is what appears in the example.
Submitter's proposal:

Change from:

For example, foo:Elem1, foo:Elem2, foo:Elem3, foo:Elem4, foo:Elem5 are all globally declared elements. Elem2 is declared with its substitutionGroup attribute referring to Elem1. The same relationship is declared between Elem3 and Elem2, and between Elem4 and Elem3, and between Elem5 and Elem4. Consider a scope with the following fault handlers:

<scope>
  <faultHandlers>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem2">
      ... catch-logic-A ...
    </catch>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem4">
      ... catch-logic-B ...
    </catch>
    <catch faultName="foo:BarFaultName">
      ... catch-logic-C ...
    </catch>
  </faultHandlers>
</scope>

If the fault data element is “foo:Elem5”, the <catch>-logic-A based on “foo:Elem4” will be matched. If fault data element is “foo:Elem3”, the <catch>-logic-B based on “foo:Elem2” will be matched. If fault data element is “foo:Elem1”, the <catch>-logic-C will be matched.

For example, foo:Elem1, foo:Elem2, foo:Elem3, foo:Elem4, foo:Elem5 are all globally declared elements. Elem2 is declared with its substitutionGroup attribute referring to Elem1. The same relationship is declared between Elem3 and Elem2, and between Elem4 and Elem3, and between Elem5 and Elem4. Consider a scope with the following fault handlers:

<scope>
  <faultHandlers>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem2">
      ... catch-logic-A ...
    </catch>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem4">
      ... catch-logic-B ...
    </catch>
    <catch faultName="foo:BarFaultName">
      ... catch-logic-C ...
    </catch>
  </faultHandlers>
</scope>

If the fault data element is “foo:Elem5”, the catch-logic-B based on “foo:Elem4” will be matched. If fault data element is “foo:Elem3”, the catch-logic-A based on “foo:Elem2” will be matched. If fault data element is “foo:Elem1”, the catch-logic-C will be matched.

As submitter's proposal
Links: Announcement, 16 Oct 2006
Changes: 16 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: In spec, Status, Change status, Resolution

Issue R21: Static Analysis requirement for Variable Reference Resolution, Section 12.7.1 and Appendix B

The variable references are resolved to the associated scope only and MUST NOT be resolved to the ancestor scopes.

Note, this text already exists as stated in Section 12.7.1.
Resolution: Proposed in Monica J. Martin, 23 Oct 2006, agreed 1 Nov 2006

See proposal in Monica J. Martin, 23 Oct 2006
Links: Announcement, 16 Oct 2006     Proposed resolution (Monica J. Martin, 23 Oct 2006)
Changes: 16 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Links, Status, Proposed resolution;    2 Nov 2006 - fields: Status, Proposed resolution, Change status, Resolution;    6 Nov 2006 - fields: In spec

Issue R22: <rethrow> of Fault Name and Fault Data Where Present

The <rethrow> activity is used in fault handlers to rethrow the fault they caught. It can be used only within a fault handler (<catch> and <catchAll>). Modifications to the fault data MUST be ignored by <rethrow>. For example, if the logic in a fault handler modifies the fault data and then call <rethrow>, the original fault data would be rethrown and not the modified fault data. Similarly if a fault is caught using the shortcut that allows message type faults with one part defined using an element to be caught by fault handlers looking for the same element type, then a <rethrow> would rethrow the original message type data (see section 12.5. Fault Handlers).

The <rethrow> activity is used in fault handlers to rethrow the fault they caught, i.e. the fault name and fault data of the original fault where present. It can be used only within a fault handler (<catch> and <catchAll>). Modifications to the fault data MUST be ignored by <rethrow>. For example, if the logic in a fault handler modifies the fault data and then call <rethrow>, the original fault data would be rethrown and not the modified fault data. Similarly if a fault is caught using the shortcut that allows message type faults with one part defined using an element to be caught by fault handlers looking for the same element type, then a <rethrow> would rethrow the original message type data (see section 12.5. Fault Handlers).

As proposed in Monica J. Martin, 18 Oct 2006
Links: Announcement, 17 Oct 2006     Proposed resolution (Monica J. Martin, 18 Oct 2006)
Changes: 17 Oct 2006 - new issue;    18 Oct 2006 - fields: Links, Status, Resolution;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R23: Clarification on Schema Variable Validation

As submitter's proposal
Links: referenced pdf document (document details)     Announcement, 17 Oct 2006
Changes: 17 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    18 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R24: Externally referenced locally-scoped partnerLinks

However, the last sentence of section 6.2 says:

The initial binding information of a <partnerLink> can be set as a part of business process deployment, regardless of whether it is declared on the <process> or <scope> element level.

What identifier should deployment descriptors use to reference these locally-scoped partnerLinks for the purpose of initializePartnerRole?
Resolution: Review and closed, conf call 1 Nov 2006

the TC reviewed this issue and voted to close it with no change to the spec. This is out of scope for the WS BPEL 2.0 spec
Links: Announcement, 17 Oct 2006     Dieter Koenig1, 18 Oct 2006     Danny van der Rijn, 18 Oct 2006     Diane Jordan, 1 Nov 2006
Changes: 17 Oct 2006 - new issue;    18 Oct 2006 - fields: Links;    2 Nov 2006 - fields: Links, Status, In spec, Resolution

Issue R25: wording for conflictingReceive and ambiguousReceive

In this constraint, "two or more receive activities" should not be interpreted as meaning "two or more instances of the same receive activity", but instead: "two or more instances of different receive activities". Indeed, it is possible that the same "receive activity" within a scope nested in an event handler or parallel foreach, is "enabled" multiple times simultaneously, possibly once for each instance of the scope. In such cases, I am assuming that "conflictingReceive" should not be thrown (otherwise, most "receive activities" appearing in a parallel foreach or event handler would unavoidably lead to faults). Consider the following example:

<foreach ... parallel="yes" ...>
  <scope>
    <partnerLinks>
       <partnerLink name="PL1" ... />
    </partnerLinks>
    <correlationSets>
       <correlationSet name="S1" ... />+
    </correlationSets>
    <invoke name="RA1" partnerLink="PL1" ... operation="OP1" inputVariable="...">
      <correlation set="S1" initiate="yes"/>
    </invoke>
    <receive name="RA" partnerLink="PL1" ... operation="OP1" ...>
      <correlation set="S1" initiate="no"/>
    </receive>
  </scope>
</foreach>

On the other hand, the following example may lead to a "conflictingReceive", as one instance of activity "RA1" may be enabled at the same time as one instance of "RA2".

<flow>
   <receive name="RA1" partnerLink="PL1" portType="PT1" operation="OP1" ...>
     <correlation set="S1" .../>
   </receive>
   <receive name="RA2" partnerLink="PL1" portType="PT1" operation="OP1">
     <correlation set="S1" .../>
   </receive>
</flow>

The first example discussed above also illustrates that the wording in the definition of "ambiguousReceive" in Appendix A warrants some clarification. The current definition says: "Thrown when a business process instance simultaneously enables two or more IMAs for the same partnerLink, portType, operation but different correlationSets, and the correlations of multiple of these activities match an incoming request message." The above is an example where two enabled instances of the same IMA may match the same incoming message.
Proposed resolution: Diane Jordan, 14 Nov 2006
Resolution: Proposed and agreed, f-t-f 15 Nov 2006

In 10.4 change to:

If during the execution of a business process instance, two or more receive activity instances for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges). There may be receive activity instances on an operation where the partnerLink and correlationSet(s) are different, yet indistinguishable to a WS-BPEL processor at runtime. In these cases, a WS-BPEL processor SHOULD throw a bpel:conflictingReceive fault. closed and applied to the spec.

Issue R26: Default Compensation Order Conflict

scope name="S0"
   flow
      scope name="S1"
         scope name="A"
            source link="fromAtoB"
         ...
      scope name="S2"
         scope name="B"
            target link="fromAtoB"
         ...
      activity name="E"

Further assume that activity "E" now throws a fault which is caught by the default fault handler of scope "S0".

1. All running activities inside of scope "S0" are terminated, and the default termination handler of scope "S1" compensates scope "A".
2. The default fault handler of scope "S0" then compensates scope "S2", which in turn compensates scope "B".

The observed compensation order "A then B" is caused by the sequence "first termination, then fault handling". OTOH, the required compensation order "B then A" implied by the control dependency of "B" on "A".

This is a contradiction.

Note that this situation cannot occur when the scope "S1" is an isolated scope. In this case, the link "fromAtoB" cannot leave the scope "S1" before it completes. In this case, scope "S1" always completes before scope "S2", and compensation of "A" cannot be caused by a termination handler before scope "B" is compensated.

Moreover, this conflict is irrelevant if scope "S1" OR scope "S2" only contain default compensation handlers, because in this case, no custom compensation logic can be executed in the wrong order.
Submitter's proposal: In order to avoid conflicts between the termination-handling / fault-handling sequence and the default compensation order, different strategies can be considered, for example, enforcing the absence of such conflicts during static analysis. A less restrictive approach is proposed here, which only affects the runtime behavior.

At the end of section 12.5.2, add the following paragraph:

"The default compensation order is initiated by default termination handlers and default fault handlers, and recursively carried forward by compensation handlers. The termination phase always precedes the fault handling phase (see section 12.6. Termination Handlers). This sequence must not create a conflict with the default compensation order of scopes that are in a control dependency relationship. If all of the following is true:

1. scope "S2" has a direct peer-scope dependency on scope "S1"
2. the scope-controlled set of activities of scope "S1" contains default termination handlers
3. the scope-controlled set of activities of scope "S1" AND scope "S2" both contain at least one custom compensation handler then a WS-BPEL processor MUST execute these scopes as if "S2" had a control dependency on scope "S1".

In section 12.5.2 From:

Rule 1: 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.

To:

Rule 1: 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 *a single* default compensation behavior, the compensation handler of B MUST run to completion before the compensation handler of A is started.

Add:

In some situations, a single fault signal can trigger multiple default compensation behaviors. Rule 1 above applies to each compensation behavior individually.

Issue R27: Faults and Parallelism in Termination Handlers

Example 1. Assume that a custom termination handler contains a parallel forEach activity or a flow activity. In either case, assume that multiple concurrent branches are active. If one branch faults, the specification does not tell whether the other branches are allowed to complete or terminated.

Example 2. Assume that a default termination handler that compensates a compensation handler instance group. If one compensation handler instance faults, the specification does not tell whether the other compensation handler instances are allowed to complete or terminated.
Submitter's proposal: Add the following to the end of section 12.6.:

"If a custom termination handler contains parallel activities and one of these activities propagates a fault then all concurrent activities in the termination handler MUST be terminated. Likewise, if a default termination handler compensates a compensation handler instance group and one of the compensation handler instances propagates a fault then the other compensation handler instances of the compensation handler instance group MUST be terminated."

Add to 12.6 before the last paragraph that starts " Forced termination of nexted ... "

A fault in a termination handler MUST cause all running contained activities to be terminated (see also Section 12.4.4.3 Compensation within FCT-Handlers).

Issue R28: IPR for WS-BPEL2.0

There is an existing IPR policy page http://www.oasis-open.org/committees/wsbpel/ipr.php, but is the statement limited to WS-BPEL1.1.

There are some questions:

Q1. Are there any essential patents to implement WS-BPEL2.0?

Q2. IPR agreements were necessary for WS-BPEL1.1. Are the same IPR agreements necessary for also WS-BPEL2.0?
Resolution: Proposed and agreed, f-t-f, 14 Nov 2006

As stated in Diane Jordan, 15 Nov 2006:

The public review process is intended for comments on the technical content of the specification. The process for IPR disclosures is different. According to OASIS process, when BPEL 2.0 started public review, a separate call for disclosure (see Mary McRae, 10 Sep 2006) was sent to TC members. If and when any updates are received they will be posted to the IPR page for the TC: http://www.oasis-open.org/committees/wsbpel/ipr.php. That is the source for any further information on this topic.
Links: Announcement, 2 Nov 2006     supporting public comment, ota hidenori, 8 Nov 2006 (public comment list)     issue R41 : IPR statements - feedback from Hitachi Ltd.     Diane Jordan, 15 Nov 2006
Changes: 2 Nov 2006 - new issue;    3 Nov 2006 - fields: Links, Origin;    9 Nov 2006 - fields: Links;    13 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Links, Status, In spec, Resolution

Issue R29: Partner link's initializePartnerRole attribute

There are a few problems with the attribute as it exists today.

1. It is only used during deployment which is something that is not covered by the specification.
2. There is no difference in the runtime behavior of the process if this attribute is “yes” or “no”. Why do we have an attribute that doesn’t affect runtime behavior?
3. It may not be meaningful to process designers since the initialization of the partner role could occur through some mechanism outside of the WS-BPEL process like a reply-to in WS-Addressing. For example, if I am designing a process that receives data and then does an invoke on the same partner link, should I set the value of the initializePartnerRole attribute to “yes” or “no”. If I’m expecting the processing of the receive to update the partner link with a reply-to endpoint then I can set it to “no”. If I expect that the deployment packaging will provide me with an endpoint then I should set it to “yes”. It seems possible that I may not know the exact bindings at the time of the process creation.

It is also worth noting that the sample process in Section 15.3.2 defines two partner links without specifying the value of the initializePartnerRole attribute. It seems unlikely that WS-Addressing would be used to initialize the partner roles for these two partner links since they are only used for invokes.
Submitter's proposal:

Remove the attribute altogether from the partner link. This would affect about 3 paragraphs in Section 6.2 along with the appendix for default values and the schema.
Resolution: Proposed and agreed, f-t-f 15 Nov 2006

Keep the the attribute, remove explanatory text and add sentance that if the attribute is not specified, partner role may be initialized by a ws-bpel processor.
Links: Announcement, 2 Nov 2006     Alex Yiu, 5 Nov 2006     Mark Ford, 6 Nov 2006     Alex Yiu, 6 Nov 2006     Chris Keller, 7 Nov 2006     Alex Yiu, 7 Nov 2006     Dieter Koenig1, 7 Nov 2006     Chris Keller, 7 Nov 2006     Alex Yiu, 7 Nov 2006     Chris Keller, 7 Nov 2006     Alex Yiu, 7 Nov 2006     Dieter Koenig1, 9 Nov 2006     Mark Ford, 10 Nov 2006     Mark Ford, 13 Nov 2006     Alex Yiu, 14 Nov 2006     Alex Yiu, 14 Nov 2006
Changes: 2 Nov 2006 - new issue;    3 Nov 2006 - fields: Links;    6 Nov 2006 - fields: Links;    7 Nov 2006 - fields: Links;    8 Nov 2006 - fields: Links;    10 Nov 2006 - fields: Links;    13 Nov 2006 - fields: Links;    14 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Status;    16 Nov 2006 - fields: In spec, Change status, Status, Resolution

Issue R30: Clarify when a <repeatEvery> expression is evaluated

Section 12.7.2 is clear about when the clock for the <repeatEvery> starts but it isn’t clear about when the expression is evaluated.
Submitter's proposal: Mark Ford, 10 Nov 2006
Resolution: Submitter's proposal amended and agreed, f-t-f 14 Nov 2006 FROM:

If the <repeatEvery> expression is specified with either the <for> or the <until> expression, the first alarm is not fired until the time specified in the <for> or <until> expression expires; thereafter it is fired repeatedly at the interval specified by the <repeatEvery> expression. If the specified duration value for <repeatEvery> is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.

If the <repeatEvery> expression is specified with either the <for> or the <until> expression, the first alarm is not fired until the time specified in the <for> or <until> expression expires; thereafter it is fired repeatedly at the interval specified by the <repeatEvery> expression. *** The duration for the <repeatEvery> is calculated when the parent scope (the scope which directly encloses the event handler) starts. *** If the specified duration value for <repeatEvery> is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.

Issue R31: Clarification for Section 10.4 Given R18 Resolution

(existing 10.4)

WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions, without reference to binding details. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding.

Reference: resolution of issue R18 (now correctly formatted in the issue list)
Submitter's proposal: Take an abbreviated approach for Section 10.4 and reference 10.3.

Change from:

WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions, without reference to binding details. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding.

WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned, such as for a SOAP binding (See Section 10.3, Invoking Web Services Operations - Invoke for fault treatment).

As submitter's proposal
Links: Announcement, 7 Nov 2006
Changes: 7 Nov 2006 - new issue;    8 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Status, Resolution, Change status, In spec

Issue R32: Correction needed in Template Process Example in Section 15.2

After reviewing the example in section 15.2, I think there are some changes needed:

1. Syntax correction from:

   <condition>"##opaque"</condition>
   

   to:

   <condition opaque="yes" />
   

2. Rectified opaque from spec usage: (because of another bug fix in other part of the spec)

   <from opaque="yes" />
   

   to

   <opaqueFrom />
   

3. Simplify partnerLink usage: Potentially, we can simplify partnerLink usage (not a bug). The number of partnerLink used in this example is a bit too many. It makes the example harder to understand. I would suggest to combine some of them.
   • "ordering" + "orderingResponse" + "orderingConfirmation" => "ordering" (initializePartnerRole="no")
   • "shipper" + "shipperResponse" => "shipper" (initializePartnerRole="yes")
   • "invoiceProcessor" + "invoiceResponse" => "invoiceProcessor" (initializePartnerRole="no")
   • "shipperRequester" unchanged (initializePartnerRole="no")

As submitter's proposal for a and b (Multiple instances of b in section 15.2)

c will be treated separately later.
Links: Announcement, 8 Nov 2006
Changes: 8 Nov 2006 - new issue;    9 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Status, Note, Resolution, Change status, In spec

Issue R33: Optional XML Data in Assignments

Another approach to address this situation is the following:

   <if>
      <condition> count($variable/optionalelement) = 1 </condition>
      <assign>
         <copy>
            <from> $variable/optionalelement </from>
            <to> ... </to>
         </copy>
      </assign>
   </if>

The downside of this is that you get a flood of activities AND that you would *not* be able to do multiple <copy>'s in an atomic way anymore (since there'd always be a check for == 1 needed).
Submitter's proposal: Introduce a new attribute suppressFromSelectionFailure="yes|no" on <copy> (the default is "no"). If set to "yes" then the <copy> would be a *no-op* instead of throwing selectionFailure when the from-spec returns zero nodes. Note that the selectionFailure would still be thrown when you try to access an nonexistent element in the *to*-spec.

Optionally - to be discussed as well - apply the following variations:

1. add the new attribute also to higher-level elements (<assign>, <scope>, <process>) in order to let multiple <copy> elements inherit its value.
2. add the new attribute to <from> instead of <copy> and let it also apply also variable initializations.

in 5.2 - add attribute to syntax
in 8.4 - add to syntax
in 8.4 - add para on ignoreMissingFromData attribute

The optional ignoreMissingFromData attribute of the <copy> construct is used to specify whether a bpel:selectionFailure standard fault is suppressed as specified in section 8.4.1. Selection Result of Copy Operations. The default value of the ignoreMissingFromData is "no".

The <copy> operation is a one-to-one replacement operation. If the optional ignoreMissingFromData attribute has the value of "yes" and the from-spec returns zero XML information items then the <copy> MUST be a "no-op"; no bpel:selectionFailure is thrown. In this case, the to-spec MUST not be evaluated. A bpel:selectionFailure MUST still be thrown in the following cases, even if the ignoreMissingFromData attribute has the value of "yes":

1. the from-spec selects multiple XML information items
2. the from-spec selects one XML information item and the to-spec does not select exactly one XML information item

If the ignoreMissingFromData attribute has the value of "no" this requires that both the from-spec and to-spec MUST select exactly one of the three information items described above. If the from-spec or to-spec do not select exactly one information item during execution, then the standard fault bpel:selectionFailure MUST be thrown. The following table illustrates the behavior of the ignoreMissingFromData attribute in the <copy> operation:

Issue R34: Fix up some minor typos

• On page 1, list of editors it still says "Mike Marin, FileNet", should be changed to either "Mike Marin, IBM" or "Mike Marin, IBM, formerly FileNet Corporation".

• On page 14, section 5.1, line 6/7, Figure 1 is referenced by "Figure 1: Purchase Order Process Online", should be "Figure 1: Purchase Order Process

• Outline" (see text under Figure 1).

• On page 22, section 5.2, line 9, according to this structure, element <variables> is mandatory within <process>. There is no "?" after "<variables>". But it should be optional as indicated in the schemas, means just add again the "?" (I assume it have been removed by error with version 1.173).

Issue R35: Wrong description of element import

"The <import> element is used within a WS-BPEL process to declare a dependency on external XML Schema or WSDL definitions. Any number of <import> elements may appear as children of the <process> element, before any other child element. Each <import> element contains one mandatory and two optional attributes."

The wrong description here is the part ", before any other child element", because child elements <documentation> and <extensions> might occur before <import>.
Submitter's proposal: Remove ", before any other child element".
Resolution: proposed and agreed, f-t-f 14 Nov 2006 As submitter's proposal
Links: Announcement, 9 Nov 2006
Changes: 9 Nov 2006 - new issue;    9 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Status, Resolution, Change status, In spec

Issue R36: Wrong description of attribute queryLanguage

"queryLanguage. This attribute specifies the query language used in the process for selection of nodes in assignment, property definition, etc. The default value for this attribute is: " urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0."

Issue R37: Wrong namespace for ServiceRefType in example

Issue R38: Wrong examples in 8.4

Example 1 on page 66 (word doc v01.182) - erroneous <expression> tag shown in bold :

<variables>
   <variable name="A" element="foo:AElement" />
   <variable name="B" element="bar:BElement" />
</variables>
...
<sequence>
   <invoke ... inputVariable="..." outputVariable="A" />
   <assign>
      <from>
         <expression>
            bpel:doXslTransform("urn:stylesheets:A2B.xsl", $A)
         </expression>
      </from>
      <to variable="B" />
   </assign>
   <invoke ... inputVariable="B" ... />
</sequence>

Example 2 on page 66/67 (word doc v1.182) - erroneous <expression> tag shown in bold:

<variables>
   <variable name="PO" element="foo:POElement" />
   <variable name="OutVar" element="foo:ItemElement" /> </variables>


<!-- ... PO is initialized ... -->


<!-- Iteratively add more items to PO until complete --> <while>
   <condition>...</condition>
   <sequence>
      <!-- Fetch next chunk into OutVar -->
      <invoke ... inputVariable="..." outputVariable="OutVar" />
      <assign>
         <copy>
            <from>
               <expression>
                  bpel:doXslTransform( "urn:stylesheets:AddToPO.xsl",
                  $PO, "NewItem", $OutVar)
               </expression>
            </from>
            <to variable="PO" />
         </copy>
      </assign>
   </sequence>
</while>

Change Example 1 to:

<variables>
   <variable name="A" element="foo:AElement" />
   <variable name="B" element="bar:BElement" />
</variables>
...
<sequence>
   <invoke ... inputVariable="..." outputVariable="A" />
   <assign>
      <from>
         bpel:doXslTransform("urn:stylesheets:A2B.xsl", $A)
      </from>
      <to variable="B" />
   </assign>
   <invoke ... inputVariable="B" ... />
</sequence>

Change Example 2 to:

<variables>
   <variable name="PO" element="foo:POElement" />
   <variable name="OutVar" element="foo:ItemElement" /> </variables>


<!-- ... PO is initialized ... -->


<!-- Iteratively add more items to PO until complete --> <while>
   <condition>...</condition>
   <sequence>
      <!-- Fetch next chunk into OutVar -->
      <invoke ... inputVariable="..." outputVariable="OutVar" />
      <assign>
         <copy>
            <from>
               bpel:doXslTransform( "urn:stylesheets:AddToPO.xsl",
               $PO, "NewItem", $OutVar)
            </from>
            <to variable="PO" />
         </copy>
      </assign>
   </sequence>
</while>

Issue R39: Make <completionCondition> element extensible

<completionCondition>?
    <branches expressionLanguage="anyURI"?
        successfulBranchesOnly="yes|no"?>?
        unsigned-integer-expression
    </branches>
    condition-element-of-other-namespace
</completionCondition>

<completionCondition>?
    <branches expressionLanguage="anyURI"?
        successfulBranchesOnly="yes|no"?>
        unsigned-integer-expression
    </branches>
</completionCondition>

When a <completionCondition> does not have any sub-elements or attributes understood by the WS-BPEL processor, it MUST be treated as if the <completionCondition> does not exist.

Also, Add (minOccurs="0") to the <branches> element in appendix D and make syntax change from submitters proposal (add ? to pseudo schema for completionCondition in 2 places (5.2 and 11.7) also make change to xsd
Links: Announcement, 10 Nov 2006
Changes: 10 Nov 2006 - new issue;    10 Nov 2006 - fields: Links;    15 Nov 2006 - fields: In spec, Status, Change status, Resolution

Issue R40: From/To Extensibility

In 8.4., add a 6th variant to <from>:

   <from from-attribute-of-another-namespace*>
   from-element-of-another-namespace*</from>

and add a 5th variant to <to>:

   <to to-attribute-of-another-namespace*>to-element-of-another-namespace*
   </to>

part 1:
Adding the <from/> and <to/> to the lists

part 2:
Add a paragraph after the literal value paragraphs (Before para starting In addition to ... )

Empty variant: The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible. Note that if these variants are not extended, or the extensions are not understood, they MUST behave as if they were an expression variant returning zero nodes.

Issue R41: IPR statements - feedback from Hitachi Ltd.

1. The page lists multiple disclosures, but there are not explicit descriptions whether newer disclosure supercedes the older ones. What is the current status?
2. Is the Siebel's disclosure unchanged after Oracle acquisition?

Matsuki Yoshino

Software Division, Hitachi Ltd.
Resolution: Proposed and agreed, f-t-f, 14 Nov 2006

As stated in Diane Jordan, 15 Nov 2006:

The public review process is intended for comments on the technical content of the specification. The process for IPR disclosures is different. According to OASIS process, when BPEL 2.0 started public review, a separate call for disclosure (see Mary McRae, 10 Sep 2006) was sent to TC members. If and when any updates are received they will be posted to the IPR page for the TC: http://www.oasis-open.org/committees/wsbpel/ipr.php. That is the source for any further information on this topic.
Links: see also issue R28     Martin Chapman, 13 Nov 2006 (public comment list)     Announcement, 14 Nov 2006     Diane Jordan, 15 Nov 2006
Changes: 13 Nov 2006 - new issue;    14 Nov 2006 - fields: Links;    15 Nov 2006 - fields: Links, Status, In spec, Resolution

Issue R42: replace HTML entity in sample with XML equivalent

The transition condition for the loan approval service contains an HTML entity for greater than or equal to.

               <transitionCondition>
                  $request.amount
                  &ge;
                  10000
               </transitionCondition>

&ge; is an HTML entity and not one of the predefined entities from XML 1.0 (Section 4.6: http://www.w3.org/TR/REC-xml/#sec-predefined-ent)
Submitter's proposal:

Change "&ge;" to "&gt;="
Resolution: proposed and agreed, f-t-f 14 Nov 2006 As submitter's proposal
Links: Announcement, 15 Nov 2006     Alex Yiu, 15 Nov 2006
Changes: 15 Nov 2006 - new issue;    15 Nov 2006 - fields: Status, Resolution, Change status, In spec, Links

Issue R43: Simplify partnerLink usage

(from issue 32, part C Simplify partnerLink usage: Potentially, we can simplify partnerLink usage (not a bug). The number of partnerLink used in this example is a bit too many. It makes the example harder to understand. I would suggest to combine some of them.

• "ordering" + "orderingResponse" + "orderingConfirmation" => "ordering" (initializePartnerRole="no")
• "shipper" + "shipperResponse" => "shipper" (initializePartnerRole="yes")
• "invoiceProcessor" + "invoiceResponse" => "invoiceProcessor" (initializePartnerRole="no")
• "shipperRequester" unchanged (initializePartnerRole="no")

As submitter's proposal, amended:

Thhe use of partnerLinks is simplified in Section 15.2, the Template Profile example, by combining the multiple partnerLinks in the example: orderingResponse into ordering, shippingResponse into shipping, and invoiceResponse into invoice, using multiple portTypes and roles to represent the request/response relationships. The use of initializePartnerRole has been updated, and shippingServiceResponse is now used as a non-opaque role for the shipper partnerLink.

(this resolution was immediately editted into the text which was then approved as the new committee draft for second public review)
Links: issue R32 : Correction needed in Template Process Example in Section 15.2     Charlton Barreto, 16 Nov 2006     Announcement, 16 Nov 2006     Charlton Barreto, 16 Nov 2006     Charlton Barreto, 16 Nov 2006
Changes: 16 Nov 2006 - new issue;    16 Nov 2006 - fields: Status, Links, In spec;    17 Nov 2006 - fields: Links;    21 Nov 2006 - fields: Change status, In spec, Resolution, Links

This file last updated 9:27 21 Nov 2006 (UTC)