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.

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

IssueIDTitleStatusProposed resolutionVote announcement
Issue 2Sub-Functionsresolution proposedIvana Trickovic, 24 Nov 2004 
Issue 9Static analysisresolution proposedYaron Y. Goland, 17 Sep 2004 
Issue 11.1Making <assign> truly extensibleresolution proposed  
Issue 12XML types and WS Interactionsresolution proposedYaron Y. Goland, 10 Dec 2004 
Issue 81Are start activities that aren't createInstance activities legal?resolution proposedYaron Y. Goland, 1 Dec 2004 
Issue 82description of abstract processes in specresolution proposedPeter Furniss, 14 Dec 2004 
Issue 91Nested Activities in Abstract Processesresolution proposedDieter Koenig1, 19 Feb 2004waiting on issue 107
Issue 92Mandatory & Optional BPEL Extensibilityresolution proposedDieter Koenig1, 21 Dec 2004 
Issue 97Optional Variable References in Abstract Processesresolution proposedDieter Koenig1, 19 Feb 2004waiting on issue 107
Issue 99Triggering activities for abstract processesresolution proposedIvana Trickovic, 10 Mar 2004waiting on issue 107
Issue 103Standardizing $varName syntax for XPath to refer to a BPEL variableresolution proposedYaron Y. Goland, 17 Sep 2004 
Issue 107Opacity and the meaning of nothingness in abstract processesresolution proposedPeter Furniss, 14 Dec 2004 
Issue 125Literal and Expression Assignment Semanticsresolution proposedYuzo Fujishima, 6 Dec 2004 
Issue 126Event Handlers with local partnerLinks & Correlation Setsresolution proposedYaron Y. Goland, 30 Jun 2004 
Issue 160facilities to define XML schema validation boundaryresolution proposedAlex Yiu, 15 Dec 2004 
Issue 169transition condition error handling clarificationresolution proposedYuzo Fujishima, 7 Dec 2004 

Issues changed or added since 28 Dec 2004

IssueIDTitleStatusIn specDate addedLast changed
Issue 11Query in <to> close should allow assigning to new locationsopen 25 Jun 20035 Jan 2005
Issue 11.1Making <assign> truly extensibleresolution proposed 5 Jan 20055 Jan 2005
Issue 92Mandatory & Optional BPEL Extensibilityresolution proposed 22 Jan 20043 Jan 2005
Issue 124PartnerLink/URI setter/getter functionresolvedno change18 May 200428 Dec 2004
Issue 130Remove Partner Elementresolvedno change6 Jul 20046 Jan 2005

Open issues by category

CategoryIssueIDTitleChampion
Abstract processesIssue 82description of abstract processes in spec 
Abstract processesIssue 91Nested Activities in Abstract Processes 
Abstract processesIssue 97Optional Variable References in Abstract Processes 
Abstract processesIssue 99Triggering activities for abstract processes 
Abstract processesIssue 107Opacity and the meaning of nothingness in abstract processes 
Abstract processesIssue 109Compatibility between Abstract and Executable Processes 
Asynchronous operationsIssue 4Dynamic parallel processing Ivana Trickovic
Asynchronous operationsIssue 63Support of Array 
Asynchronous operationsIssue 147Serial and Parallel For-Each 
CorrelationIssue 11Query in <to> close should allow assigning to new locationsDanny van der Rijn
CorrelationIssue 11.1Making <assign> truly extensibleAlex Yiu
CorrelationIssue 26Correlating use with receive/replyAssaf Arkin
CorrelationIssue 96Engine-managed correlation sets 
CorrelationIssue 120What are the semantics when an initial <receive> has no correlation set? 
CorrelationIssue 126Event Handlers with local partnerLinks & Correlation Sets 
Data HandlingIssue 156Cleaning Up XPATH in BPEL 
Data HandlingIssue 157Cleaning up copy 
Data handlingIssue 11Query in <to> close should allow assigning to new locationsDanny van der Rijn
Data handlingIssue 11.1Making <assign> truly extensibleAlex Yiu
Data handlingIssue 12XML types and WS Interactions 
Data handlingIssue 51Section 9.3.1 & Schema Validation 
Data handlingIssue 63Support of Array 
Data handlingIssue 102Fixing Typos in getVariable*() in BPEL examples 
Data handlingIssue 103Standardizing $varName syntax for XPath to refer to a BPEL variable 
Data handlingIssue 112Input/Output Elements on Messaging Activities 
Data handlingIssue 153getVariableData xpath function should return node sets of any size  
Event handlingIssue 126Event Handlers with local partnerLinks & Correlation Sets 
ExpressionsIssue 6Completion Condition 
ExpressionsIssue 28Simplification of join conditionAssaf Arkin
ExpressionsIssue 29Simplification of XPath expressionsAssaf Arkin
ExpressionsIssue 51Section 9.3.1 & Schema Validation 
ExpressionsIssue 125Literal and Expression Assignment Semantics 
Fault handlingIssue 133Access to unnamed fault bodies 
Fault handlingIssue 141Standard Fault Format 
Fault handlingIssue 180Clarification of WSDL fault declarations and Reply in BPEL 
Partner linksIssue 126Event Handlers with local partnerLinks & Correlation Sets 
Partner linksIssue 139PartnerLink Semantics 
Process lifecycleIssue 81Are start activities that aren't createInstance activities legal? 
Related StandardsIssue 180Clarification of WSDL fault declarations and Reply in BPEL 
Related standardsIssue 86Addressing Interoperability / Portability - SOAP 1.2 
Related standardsIssue 154doc/lit & multiple body parts 
Related standardsIssue 174Are multiple imports with the same namespace allowed? 
ScopesIssue 119Transition Conditions and Invoke Fault Handlers 
Specification editingIssue 144Defining Undefined Behaviors 
Specification editingIssue 148Explicitly state that solicit/response & notification aren't supported by BPEL 
Specification editingIssue 158Changing Spec Structure from 3 part to 2 part 
Specification editingIssue 159Ordering specification sections by dependency 
State managementIssue 2Sub-FunctionsIvana Trickovic
State managementIssue 6Completion Condition 
State managementIssue 28Simplification of join conditionAssaf Arkin
State managementIssue 81Are start activities that aren't createInstance activities legal? 
State managementIssue 119Transition Conditions and Invoke Fault Handlers 
State managementIssue 142Break & Continue 
State managementIssue 147Serial and Parallel For-Each 
SubprocessesIssue 2Sub-FunctionsIvana Trickovic
Syntax & semanticsIssue 177Inconsistent optional/required nature of @Variable on onMessage, onEvent and Receive 
Syntax and validationIssue 9Static analysis 
Syntax and validationIssue 88Import Errata 
Syntax and validationIssue 92Mandatory & Optional BPEL Extensibility 
Syntax and validationIssue 110Issues with the Pattern Attribute 
Syntax and validationIssue 111Extension Activities 
Syntax and validationIssue 125Literal and Expression Assignment Semantics 
Syntax and validationIssue 132In-line Variable Initialization 
Syntax and validationIssue 136If-Then-Else Activity 
Syntax and validationIssue 138Properties of type element 
Syntax and validationIssue 140Until Activity 
Syntax and validationIssue 142Break & Continue 
Syntax and validationIssue 143StaticSwitch Activity 
Syntax and validationIssue 147Serial and Parallel For-Each 
Syntax and validationIssue 150Message variables on invoke and reply 
Syntax and validationIssue 160facilities to define XML schema validation boundary 
Syntax and validationIssue 163languageExecutionFault 
Syntax and validationIssue 181uninitializedVariable cleanup 
syntax & semanticsIssue 169transition condition error handling clarificationYuzo Fujishima

Open issues with no identified traffic since 22 Sep 2004

IssueIDTitleDate addedLast changedChampion
Issue 4Dynamic parallel processing 25 Jun 20032 Jun 2004Ivana Trickovic
Issue 9Static analysis25 Jun 200317 Sep 2004 
Issue 26Correlating use with receive/reply26 Jun 200315 Jan 2004Assaf Arkin
Issue 28Simplification of join condition26 Jun 200320 Oct 2003Assaf Arkin
Issue 29Simplification of XPath expressions26 Jun 200321 Oct 2003Assaf Arkin
Issue 63Support of Array15 Sep 200322 Apr 2004 
Issue 86Addressing Interoperability / Portability - SOAP 1.225 Nov 200327 Nov 2003 
Issue 88Import Errata3 Dec 200323 Jun 2004 
Issue 91Nested Activities in Abstract Processes22 Jan 200429 Apr 2004 
Issue 96Engine-managed correlation sets3 Feb 200422 Jun 2004 
Issue 97Optional Variable References in Abstract Processes10 Feb 200429 Apr 2004 
Issue 99Triggering activities for abstract processes3 Mar 200423 Jun 2004 
Issue 102Fixing Typos in getVariable*() in BPEL examples9 Mar 200422 Apr 2004 
Issue 109Compatibility between Abstract and Executable Processes24 Mar 200417 Aug 2004 
Issue 111Extension Activities25 Mar 200425 Mar 2004 
Issue 112Input/Output Elements on Messaging Activities25 Mar 200424 Jun 2004 
Issue 120What are the semantics when an initial <receive> has no correlation set?19 Apr 200427 Aug 2004 
Issue 126Event Handlers with local partnerLinks & Correlation Sets10 Jun 200415 Jul 2004 
Issue 132In-line Variable Initialization15 Jul 200416 Jul 2004 
Issue 133Access to unnamed fault bodies15 Jul 200416 Jul 2004 
Issue 136If-Then-Else Activity15 Jul 200416 Jul 2004 
Issue 138Properties of type element15 Jul 200415 Sep 2004 
Issue 139PartnerLink Semantics15 Jul 20044 Aug 2004 
Issue 140Until Activity15 Jul 200416 Jul 2004 
Issue 141Standard Fault Format15 Jul 200416 Jul 2004 
Issue 143StaticSwitch Activity15 Jul 200416 Jul 2004 
Issue 144Defining Undefined Behaviors15 Jul 200416 Jul 2004 
Issue 147Serial and Parallel For-Each16 Jul 200420 Sep 2004 
Issue 148Explicitly state that solicit/response & notification aren't supported by BPEL17 Jul 200417 Jul 2004 
Issue 150Message variables on invoke and reply20 Jul 200421 Jul 2004 
Issue 153getVariableData xpath function should return node sets of any size 27 Jul 200427 Jul 2004 
Issue 154doc/lit & multiple body parts28 Jul 200430 Jul 2004 
Issue 156Cleaning Up XPATH in BPEL31 Jul 200431 Jul 2004 
Issue 157Cleaning up copy31 Jul 200431 Jul 2004 
Issue 158Changing Spec Structure from 3 part to 2 part4 Aug 20047 Aug 2004 
Issue 159Ordering specification sections by dependency4 Aug 20046 Aug 2004 

Resolved issues awaiting editing into spec

IssueIDTitleLast changed
Issue 84Require Static Analysis Description & List23 Jun 2004
Issue 93Use of XML types in faults14 Dec 2004
Issue 105XML namespaces used in spec and examples need to be defined24 Jun 2004
Issue 145Properties on Non-Message Variables16 Dec 2004
Issue 155complexType Variables9 Dec 2004
Issue 162Unique Activity Names for Compensate15 Dec 2004
Issue 167Rethrow semantics clarification27 Oct 2004
Issue 170How to handle faultcode, faultstring, and faultactor3 Dec 2004
Issue 171faultName should be optional for invoke fault handlers15 Dec 2004

All issues, in order

IssueIDTitleStatusIn specDate addedLast changedRevisitable
Issue 1Permeability of scopesresolved5 Oct 200425 Jun 20036 Oct 2004 
Issue 2Sub-Functionsresolution proposed 25 Jun 200310 Dec 2004 
Issue 3Current state influence in compensation handlersresolved4 June 200425 Jun 20039 Jun 2004 
Issue 4Dynamic parallel processing open 25 Jun 20032 Jun 2004 
Issue 5Suspend/resumeresolvedno change25 Jun 200311 Feb 2004 
Issue 6Completion Conditionopen 25 Jun 200320 Dec 2004 
Issue 7Import resolved4 June 200425 Jun 20039 Jun 2004 
Issue 8Non-mutability of correlation setsresolvedNo change25 Jun 200322 Jun 2004 
Issue 9Static analysisresolution proposed 25 Jun 200317 Sep 2004 
Issue 10Serialization of compensationresolved19 Nov 200425 Jun 200319 Nov 2004 
Issue 11Query in <to> close should allow assigning to new locationsopen 25 Jun 20035 Jan 2005 
Issue 11.1Making <assign> truly extensibleresolution proposed 5 Jan 20055 Jan 2005 
Issue 12XML types and WS Interactionsresolution proposed 25 Jun 200314 Dec 2004 
Issue 13Future Usage of XPATH 2.0 and XQuery 1.0resolved4 June 200425 Jun 200326 Jul 2004 
Issue 14Restriction on join conditionsresolvedno change25 Jun 20034 Feb 2004 
Issue 15WSDL MEPsresolvedNo change25 Jun 20036 Oct 2004 
Issue 16Ensuring exactly onceresolvedno change25 Jun 200310 Dec 2003 
Issue 17Asynchronous operationsresolvedno change25 Jun 200327 Jan 2004 
Issue 18BPEL Visual Bindingresolvedno change25 Jun 200311 Feb 2004 
Issue 19Multiple properties associated to a single property aliasresolvedno change25 Jun 200311 Feb 2004 
Issue 20installing compensation handlers for faulted scopesresolvedno change25 Jun 20031 Oct 2003 
Issue 21faultHandlers to be renamed cancellationHandlersresolvedno change25 Jun 20033 Mar 2004 
Issue 22Implicit <sequence> macroresolvedno change25 Jun 20034 Feb 2004 
Issue 23Rationale for sequence vs. flow resolved4 June 200425 Jun 20039 Jun 2004 
Issue 24Separate schemas for executable vs abstract BPELresolvedno change25 Jun 200311 May 2004 
Issue 25Consistent enablement of compensation handlersresolved1.34, 19 June 200426 Jun 200320 Jun 2004 
Issue 26Correlating use with receive/replyopen 26 Jun 200315 Jan 2004 
Issue 27Setting link status in case of transition conditionresolved4 June 200426 Jun 20039 Jun 2004 
Issue 28Simplification of join conditionopen 26 Jun 200320 Oct 2003 
Issue 29Simplification of XPath expressionsopen 26 Jun 200321 Oct 2003 
Issue 30Support for coordination protocolresolved1.34, 19 June 200426 Jun 200320 Jun 2004Yes
Issue 31Unique identifier for establishing new correlationresolvedNo change26 Jun 200322 Jun 2004Yes
Issue 32Link Semantics in Event Handlersresolved4 June 20043 Jul 20039 Jun 2004 
Issue 33Race condition before correlation set is establishedresolved1.34, 19 June 20049 Jul 200320 Jun 2004 
Issue 34Dependency on Proprietary Specificationsresolved16 Aug 20049 Jul 200317 Aug 2004 
Issue 35Support for modelingresolvedno change9 Jul 200311 Feb 2004 
Issue 36Multiple instances of event handlerresolved4 June 20049 Jul 20039 Jun 2004 
Issue 37Initiating Correlation Set More Than Onceresolved1.35, 30 June 200411 Jul 200315 Jul 2004 
Issue 38Directed Activity Graph and block structuredresolvedno change13 Jul 20034 Feb 2004 
Issue 39Inconsistent syntax for query attribute values in spec examplesresolved4 June 200416 Jul 20039 Jun 2004 
Issue 40attribute name "variable" or "message"resolvedno change24 Jul 20039 Jun 2004 
Issue 41onMessage handler definitionresolved4 June 200431 Jul 20039 Jun 2004 
Issue 42Need for Formalismresolvedno change31 Jul 20033 Mar 2004yes
Issue 43Setting up Periodic Alarmsresolved16 Aug 200431 Jul 200317 Aug 2004 
Issue 44portType is duplicated on Invoke activity and partnerLinkTyperesolved16 Aug 20045 Aug 200317 Aug 2004 
Issue 45Wording of "while" activityresolved4 June 20047 Aug 20039 Jun 2004 
Issue 46Namespace for the document fragment representing a partresolved4 June 20047 Aug 20039 Jun 2004 
Issue 47Which Version of WSDL should we use?resolvedno change8 Aug 200315 Oct 2003 
Issue 48XML Transform Supportresolvedno change12 Aug 200329 Apr 2004 
Issue 49Disambiguating <receive>s to <reply> toresolvedno change12 Aug 200327 Jan 2004 
Issue 50Semantics for "dangling receive"resolved4 June 200412 Aug 20039 Jun 2004 
Issue 51Section 9.3.1 & Schema Validationopen 18 Aug 200325 Nov 2004 
Issue 52Specify how flows in the same process send messages to each otherresolvedNo change18 Aug 200323 Sep 2004 
Issue 53Include Business Transaction Management (BTM) constructsresolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 54Construct to hold Business transaction contexts resolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 55Business transaction propagation resolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 56Business transaction creationresolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 57Business transaction terminationresolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 58Selective termination of business transaction participantsresolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 59BPEL process as business transaction participant resolved1.34, 19 June 200426 Aug 200320 Jun 2004Yes
Issue 60process categoryresolvedno change8 Sep 200311 Feb 2004 
Issue 61process priorityresolvedno change8 Sep 200311 Feb 2004 
Issue 62Event handlers and Serializable Scopesresolved4 June 200412 Sep 20039 Jun 2004 
Issue 63Support of Arrayopen 15 Sep 200322 Apr 2004 
Issue 64Explicit declaration of process instantiationresolvedNo change15 Sep 200314 Oct 2004 
Issue 65Multiple partners of a partner typeresolvedNo change15 Sep 200322 Jun 2004 
Issue 66Zero or multiple matches of correlation setresolvedNo change19 Sep 200322 Jun 2004 
Issue 67Clarify semantics of serializable scopesresolved4 June 200424 Sep 20039 Jun 2004 
Issue 68catch syntax brokenresolved4 June 200426 Sep 20039 Jun 2004 
Issue 69When to clear link statusresolved4 June 200427 Sep 20039 Jun 2004 
Issue 70suppressJoinFailure default valueresolved4 June 200430 Sep 20039 Jun 2004 
Issue 71Removal of wsdl:messageresolvedNo change1 Oct 200314 Oct 2004 
Issue 72What to do with WS-I BP1.0? resolved4 June 20041 Oct 20039 Jun 2004 
Issue 73"wsdl:fault" element not allowed with one-way operationresolved4 June 20046 Oct 20039 Jun 2004 
Issue 74Ambiguity in join condition definitionresolved4 June 20049 Oct 20039 Jun 2004 
Issue 75Locally Scoped partnerLink declarationsresolved1.35, 30 June 200421 Oct 200315 Jul 2004 
Issue 76Mandating either Pessimistic or Optimistic Static Analysisresolvedno change21 Oct 200312 Nov 2003 
Issue 77BPEL cannot handle some SOAP header bindingsresolvedno change21 Oct 200310 Dec 2003 
Issue 78New value for initiate on multi-startsresolvedNo change22 Oct 200322 Jun 2004 
Issue 79Serializable scopes do not need to be leaf scopesresolved4 June 200422 Oct 20039 Jun 2004 
Issue 80Clarify Fault Handler Selection When Fault Data is Absentresolved4 June 200431 Oct 20039 Jun 2004 
Issue 81Are start activities that aren't createInstance activities legal?resolution proposed 3 Nov 20037 Dec 2004 
Issue 82description of abstract processes in specresolution proposed 3 Nov 200316 Dec 2004 
Issue 83Garbage Collecting Compensation Handlersresolvedno change3 Nov 200320 May 2004Yes
Issue 84Require Static Analysis Description & Listresolved 5 Nov 200323 Jun 2004 
Issue 85Multiple links with the same source and targetresolved4 June 200417 Nov 20039 Jun 2004 
Issue 86Addressing Interoperability / Portability - SOAP 1.2open 25 Nov 200327 Nov 2003 
Issue 87Optional SOAP HeadersresolvedNo change27 Nov 20038 Dec 2004Yes
Issue 87.1Optional SOAP Headers (subissue: generic mechanism)resolvedNo change 8 Dec 2004 
Issue 88Import Errataopen 3 Dec 200323 Jun 2004 
Issue 89Handling Unrecognized Query/Expression Languagesresolved16 Nov 20047 Jan 200417 Nov 2004 
Issue 90Assignment of external data into a variableresolvedno change9 Jan 200429 Apr 2004Yes
Issue 91Nested Activities in Abstract Processesresolution proposed 22 Jan 200429 Apr 2004 
Issue 92Mandatory & Optional BPEL Extensibilityresolution proposed 22 Jan 20043 Jan 2005 
Issue 93Use of XML types in faultsresolved 22 Jan 200414 Dec 2004 
Issue 94Allow both "compensate" and other activities in compensation or fault handlerresolved1.35, 30 June 20042 Feb 200415 Jul 2004 
Issue 95Rethrow a Faultresolved4 June 20043 Feb 20049 Jun 2004 
Issue 96Engine-managed correlation setsopen 3 Feb 200422 Jun 2004 
Issue 97Optional Variable References in Abstract Processesresolution proposed 10 Feb 200429 Apr 2004 
Issue 98What version number are we working towardsresolved19 Nov 200420 Feb 200419 Nov 2004 
Issue 99Triggering activities for abstract processesresolution proposed 3 Mar 200423 Jun 2004 
Issue 100When should XML be validated?resolvedNo change4 Mar 200423 Jun 2004 
Issue 101Local variables overriding enclosing scoperesolved4 June 20045 Mar 20049 Jun 2004 
Issue 102Fixing Typos in getVariable*() in BPEL examplesopen 9 Mar 200422 Apr 2004 
Issue 103Standardizing $varName syntax for XPath to refer to a BPEL variableresolution proposed 9 Mar 200430 Sep 2004 
Issue 104incorrect target link names in 12.5.3. Flow Graphresolved4 June 200410 Mar 20049 Jun 2004 
Issue 105XML namespaces used in spec and examples need to be definedresolved 17 Mar 200424 Jun 2004 
Issue 106ASSERT activity.resolvedNo change18 Mar 200423 Jun 2004 
Issue 107Opacity and the meaning of nothingness in abstract processesresolution proposed 18 Mar 200414 Dec 2004 
Issue 108Parallel Compensationresolved19 Nov 0420 Mar 200424 Nov 2004 
Issue 109Compatibility between Abstract and Executable Processesopen 24 Mar 200417 Aug 2004 
Issue 110Issues with the Pattern Attributeopen 24 Mar 200414 Oct 2004 
Issue 111Extension Activitiesopen 25 Mar 200425 Mar 2004 
Issue 112Input/Output Elements on Messaging Activitiesopen 25 Mar 200424 Jun 2004 
Issue 113Optional Port TypesresolvedNo change25 Mar 200423 Jun 2004 
Issue 114Multiple Correlation Setsresolved1.35, 30 June 200431 Mar 200415 Jul 2004 
Issue 115Revise content of Appendix CresolvedNo change1 Apr 200423 Sep 2004 
Issue 116<process> element should be optionalresolvedNo change1 Apr 200427 Oct 2004 
Issue 117Link Name Scopingresolved4 June 200414 Apr 20049 Jun 2004 
Issue 118When are Correlation Sets Mandatory?resolvedno change15 Apr 20047 Jul 2004 
Issue 119Transition Conditions and Invoke Fault Handlersopen 19 Apr 200412 Oct 2004 
Issue 120What are the semantics when an initial <receive> has no correlation set?open 19 Apr 200427 Aug 2004 
Issue 121<finally> constructresolvedNo change20 Apr 200414 Dec 2004Yes
Issue 122Clarify wording for Message Exchange PatternsresolvedNo change20 Apr 200423 Jun 2004 
Issue 123Matching <reply> with <receive>resolved21 Oct 200418 May 200423 Oct 2004 
Issue 124PartnerLink/URI setter/getter functionresolvedno change18 May 200428 Dec 2004Yes
Issue 125Literal and Expression Assignment Semanticsresolution proposed 25 May 20048 Dec 2004 
Issue 126Event Handlers with local partnerLinks & Correlation Setsresolution proposed 10 Jun 200415 Jul 2004 
Issue 127Locally Scoped Partnersresolvedno change11 Jun 200412 Jun 2004 
Issue 128WS-I BP Incompatible WSDL Importresolved16 Aug 200414 Jun 200417 Aug 2004 
Issue 129Inconsistent Name Attribute Usage in PartnerLinkTyperesolved16 Nov 200414 Jun 200417 Nov 2004 
Issue 130Remove Partner Elementresolvedno change6 Jul 20046 Jan 2005 
Issue 131revisiting section 9.3.1 "Type Compatibility in Assignment"resolvedNo change13 Jul 200416 Jul 2004 
Issue 132In-line Variable Initializationopen 15 Jul 200416 Jul 2004 
Issue 133Access to unnamed fault bodiesopen 15 Jul 200416 Jul 2004 
Issue 134Non-Integer XPATHSresolved21 Oct 200415 Jul 200423 Oct 2004 
Issue 135Clarifying forcedTermination Handlerresolved19 Nov 200415 Jul 200419 Nov 2004 
Issue 136If-Then-Else Activityopen 15 Jul 200416 Jul 2004 
Issue 137Making properties consistent with variable valuesresolved25 Nov 0415 Jul 200425 Nov 2004 
Issue 138Properties of type elementopen 15 Jul 200415 Sep 2004 
Issue 139PartnerLink Semanticsopen 15 Jul 20044 Aug 2004 
Issue 140Until Activityopen 15 Jul 200416 Jul 2004 
Issue 141Standard Fault Formatopen 15 Jul 200416 Jul 2004 
Issue 142Break & Continueopen 15 Jul 20048 Dec 2004 
Issue 143StaticSwitch Activityopen 15 Jul 200416 Jul 2004 
Issue 144Defining Undefined Behaviorsopen 15 Jul 200416 Jul 2004 
Issue 145Properties on Non-Message Variablesresolved 15 Jul 200416 Dec 2004 
Issue 146Making tVariable Extensibleresolved8 Sept 200415 Jul 200415 Sep 2004 
Issue 147Serial and Parallel For-Eachopen 16 Jul 200420 Sep 2004 
Issue 148Explicitly state that solicit/response & notification aren't supported by BPELopen 17 Jul 200417 Jul 2004 
Issue 149adding formal <documentation> support to BPEL resolved8 Sept 200420 Jul 200415 Sep 2004 
Issue 150Message variables on invoke and replyopen 20 Jul 200421 Jul 2004 
Issue 151Allow a new process instance to be created by "pick onAlarm until"resolvedno change26 Jul 200415 Sep 2004yes
Issue 152Clarification of usage of "reference-scheme" attribute of "service-ref" elementresolved3 Dec 200427 Jul 20044 Dec 2004 
Issue 153getVariableData xpath function should return node sets of any size open 27 Jul 200427 Jul 2004 
Issue 154doc/lit & multiple body partsopen 28 Jul 200430 Jul 2004 
Issue 155complexType Variablesresolved 28 Jul 20049 Dec 2004 
Issue 156Cleaning Up XPATH in BPELopen 31 Jul 200431 Jul 2004 
Issue 157Cleaning up copyopen 31 Jul 200431 Jul 2004 
Issue 158Changing Spec Structure from 3 part to 2 partopen 4 Aug 20047 Aug 2004 
Issue 159Ordering specification sections by dependencyopen 4 Aug 20046 Aug 2004 
Issue 160facilities to define XML schema validation boundaryresolution proposed 10 Aug 200416 Dec 2004 
Issue 161Explicit conformance statementsresolvedNo change8 Sep 200429 Sep 2004Yes
Issue 162Unique Activity Names for Compensateresolved 8 Sep 200415 Dec 2004 
Issue 163languageExecutionFaultopen 22 Sep 200414 Oct 2004 
Issue 164Variable Types for Throw and CatchresolvedDuplicate23 Sep 200414 Oct 2004 
Issue 165clarification of the default NS URI for expression and query languageresolved3 Dec 200423 Sep 20044 Dec 2004 
Issue 166Does atomicity in assign imply variable locking?resolved25 Nov 0429 Sep 200425 Nov 2004 
Issue 167Rethrow semantics clarificationresolved 4 Oct 200427 Oct 2004 
Issue 168Semantics of instance creationresolvedNo change4 Oct 20048 Dec 2004 
Issue 169transition condition error handling clarificationresolution proposed 18 Oct 200410 Dec 2004 
Issue 170How to handle faultcode, faultstring, and faultactorresolved 18 Oct 20043 Dec 2004 
Issue 171faultName should be optional for invoke fault handlersresolved 18 Oct 200415 Dec 2004 
Issue 172Clarification/correction of correlation sets example in sec. 10.2resolved25 Nov 0418 Oct 200425 Nov 2004 
Issue 173Value of initiate attributes in Multiple Start Activities exampleresolved25 Nov 0420 Oct 200425 Nov 2004 
Issue 174Are multiple imports with the same namespace allowed?open 23 Oct 200411 Nov 2004 
Issue 175Supporting WSDL Overloading in BPELresolved25 Nov 0427 Oct 200425 Nov 2004 
Issue 176Removing Section 4resolved19 Nov 200427 Oct 200419 Nov 2004 
Issue 177Inconsistent optional/required nature of @Variable on onMessage, onEvent and Receiveopen 28 Oct 200411 Nov 2004 
Issue 178Correlation sets visible to an event handlerresolved25 Nov 042 Nov 200425 Nov 2004 
Issue 179Type Compatibility in Assignment of EPRsresolvedNo change12 Nov 200424 Nov 2004 
Issue 180Clarification of WSDL fault declarations and Reply in BPELopen 4 Dec 20048 Dec 2004 
Issue 181uninitializedVariable cleanupopen 10 Dec 200414 Dec 2004 

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

Status: resolved
In spec: 5 Oct 2004
Date added: 25 Jun 2003
Categories: Scopes, State management, Compensation
Origin: Initial requirements log, item 1 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Dieter Roller
Document: BPEL specification
Description:
Currently scopes are "permeable" in the sense that the status of links that are used for activity synchronization is visible outside the scope before the scope completes. This has problematic implications in case the scope faults. Should we support non-permeable scopes, i.e., scopes that make the status of links that are used for activity synchronization invisible outside the scope until the scope completes (normally or abnormally). Should we support the notion of non-permeable scopes? Only non-permeable scopes? Both?
Qualifier: requirement
Resolution: Proposed in Satish Thatte, 18 Jun 2004, decided at San Francisco f-t-f

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>

Where a scope is said to be permeable if link status can travel freely across its boundaries as in the present specification. The status of links leaving (source inside target outside) a non-permeable scope will not be visible at the target until the scope completes, whether successfully or unsuccessfully. If the scope completes unsuccessfully, the status of links leaving the scope is false regardless of what it was at the time the source activity completed. There is no change for links entering (source outside target inside) the non-permeable 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

Status: resolution proposed
Date added: 25 Jun 2003
Categories: Subprocesses, State management
Origin: Initial requirements log, item 2 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Ivana Trickovic
Document: BPEL specification
Description:
A mechanism is needed that provides the capability to package standard bits of BPEL functionality and call them as sub-processes from within another BPEL process. Data to be exchanged between the calling process and the sub-processes is via parameter passing. Two mechanisms are proposed: a <call> activity that invokes the sub-process and waits until the sub-process has completed and a <spawn> activity that creates an instance of the sub-process with its own lifecycle and continues without waiting for the new instance to complete.
Qualifier: requirement
Proposed resolution: Ivana Trickovic, 24 Nov 2004
Links: Announcement, 25 Jun 2003     Eckenfels. Bernd, 22 Jul 2003     Kevin Liu, 22 Jul 2003     Assaf Arkin, 23 Jul 2003     Ivana Trickovic, 29 Oct 2003     Yaron Goland, 29 Oct 2003     Edwin Khodabakchian, 29 Oct 2003     Yaron Goland, 29 Oct 2003     Chris Keller, 30 Oct 2003     Nickolas Kavantzas, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Harvey Reed, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Harvey Reed, 30 Oct 2003     Ron Ten-Hove, 30 Oct 2003     Yaron Goland, 30 Oct 2003     Yaron Goland, 30 Oct 2003     Yaron Goland, 31 Oct 2003     Yaron Goland, 31 Oct 2003     Frank Leymann, 31 Oct 2003     Harvey Reed, 31 Oct 2003     Ivana Trickovic, 31 Oct 2003     Yaron Goland, 31 Oct 2003     Ron Ten-Hove, 1 Nov 2003     Yaron Goland, 3 Nov 2003     Yaron Goland, 3 Nov 2003     Yaron Goland, 3 Nov 2003     Satish Thatte, 5 Nov 2003     Satish Thatte, 5 Nov 2003     Ugo Corda, 5 Nov 2003     Satish Thatte, 6 Nov 2003     Ron Ten-Hove, 6 Nov 2003     Ugo Corda, 6 Nov 2003     Harvey Reed, 6 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Ugo Corda, 7 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Ron Ten-Hove, 7 Nov 2003     Harvey Reed, 7 Nov 2003     Monica J. Martin, 10 Nov 2003     Ivana Trickovic, 10 Nov 2003     Eckenfels. Bernd, 12 Nov 2003     Ugo Corda, 12 Nov 2003     Ivana Trickovic, 14 Nov 2003     Yaron Goland, 25 Nov 2003     Edwin Khodabakchian, 25 Nov 2003     Assaf Arkin, 25 Nov 2003     Harvey Reed, 25 Nov 2003     Ron Ten-Hove, 25 Nov 2003     Ivana Trickovic, 26 Nov 2003     Peter Furniss, 26 Nov 2003     Eckenfels. Bernd, 26 Nov 2003     Post-Melbourne discussion on coordination questions is under issue 30 issue 30     Proposed resolution (Yaron Y. Goland, 16 Jun 2004)     Dieter Koenig1, 17 Jun 2004     Satish Thatte, 18 Jun 2004     Discussed at San Francisco f-t-f     Ivana Trickovic, 21 Jul 2004     Satish Thatte, 21 Jul 2004     Ivana Trickovic, 22 Jul 2004     Frank.Leymann@t-online.de, 23 Jul 2004     Yaron Y. Goland, 23 Jul 2004     Ivana Trickovic, 4 Aug 2004     Ivana Trickovic, 4 Aug 2004     Yaron Y. Goland, 6 Aug 2004     Ivana Trickovic, 27 Aug 2004     Yaron Y. Goland, 9 Sep 2004     Proposed resolution (Ivana Trickovic, 15 Sep 2004)     Ivana Trickovic, 21 Sep 2004     Ivana Trickovic, 23 Sep 2004     Maciej Szefler, 25 Sep 2004     Ivana Trickovic, 28 Sep 2004     Peter Furniss, 28 Sep 2004     Maciej Szefler, 28 Sep 2004     Maciej Szefler, 28 Sep 2004     Chris Keller, 29 Sep 2004     Proposed resolution (Ivana Trickovic, 24 Nov 2004)     Ivana Trickovic, 8 Dec 2004     Satish Thatte, 9 Dec 2004
Changes: 4 Jul 2003 - fields: Document;    22 Jul 2003 - fields: Links;    23 Jul 2003 - fields: Links;    24 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    30 Oct 2003 - fields: Links;    31 Oct 2003 - fields: Links;    1 Nov 2003 - fields: Links;    3 Nov 2003 - fields: Links;    5 Nov 2003 - fields: Links;    6 Nov 2003 - fields: Links;    7 Nov 2003 - fields: Links;    8 Nov 2003 - fields: Links;    10 Nov 2003 - fields: Links;    12 Nov 2003 - fields: Links;    13 Nov 2003 - fields: Links;    16 Nov 2003 - fields: Links;    26 Nov 2003 - fields: Links;    9 Dec 2003 - fields: Links;    2 Jun 2004 - fields: Champion;    16 Jun 2004 - fields: Links, Status, Proposed resolution;    17 Jun 2004 - fields: Links;    19 Jun 2004 - fields: Links;    24 Jun 2004 - fields: Links;    21 Jul 2004 - fields: Links;    22 Jul 2004 - fields: Links;    23 Jul 2004 - fields: Links;    4 Aug 2004 - fields: Links;    7 Aug 2004 - fields: Links;    27 Aug 2004 - fields: Links;    9 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    21 Sep 2004 - fields: Links;    23 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    29 Sep 2004 - fields: Links;    30 Sep 2004 - fields: Links;    24 Nov 2004 - fields: Links, Status, Proposed resolution;    8 Dec 2004 - fields: Links;    10 Dec 2004 - fields: Links

Issue 3: Current state influence in compensation handlers

Status: resolved
In spec: 4 June 2004
Date added: 25 Jun 2003
Origin: Initial requirements log, item 3 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Satish Thatte
Document: BPEL specification
Description:
Compensation handlers currently only see the data in the state of the process as it existed when the scope completed. There is a need to have the current state available within compensation handlers. It is proposed to have parameters for compensation handlers where the parameters represent inward and outward flow for current state data.
Qualifier: requirement
Proposed resolution: Satish Thatte, 12 Oct 2003
Resolution: Proposed in Satish Thatte, 12 Oct 2003, approved at TC conf call meeting, 29 Oct 2003 (document details)

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.


Links: Announcement, 25 Jun 2003     Peter Furniss, 7 Aug 2003     Discussed at meeting, 6 August (document details)     Satish Thatte, 15 Sep 2003     Discussed at Redmond face-to-face - Satish's presentation (document details)     sub points identified in discussion     Proposal for discussion (Satish Thatte, 8 Oct 2003)     Satish Thatte, 8 Oct 2003     jim@parasoft.com, 8 Oct 2003     Yaron Goland, 8 Oct 2003     Satish Thatte, 8 Oct 2003     Harvey Reed, 8 Oct 2003     Edwin Khodabakchian, 8 Oct 2003     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     Satish Thatte, 9 Oct 2003     jim@parasoft.com, 10 Oct 2003     Satish Thatte, 10 Oct 2003     Assaf Arkin, 11 Oct 2003     Satish Thatte, 11 Oct 2003     Proposed resolution (Satish Thatte, 12 Oct 2003)     Aniruddha Thakur, 28 Oct 2003     Satish Thatte, 29 Oct 2003     Aniruddha Thakur, 29 Oct 2003     Muruga Chinnananchi, 28 Jan 2004     Muruga Chinnananchi, 29 Jan 2004     Satish Thatte, 1 Feb 2004
Changes: 4 Jul 2003 - fields: Document;    7 Aug 2003 - fields: Links, Links;    10 Sep 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    8 Oct 2003 - fields: Links;    9 Oct 2003 - fields: Links;    11 Oct 2003 - fields: Links;    12 Oct 2003 - fields: Links, Proposed resolution, Status;    29 Oct 2003 - fields: Links;    4 Nov 2003 - fields: Status, Resolution;    2 Feb 2004 - fields: Links;    9 Jun 2004 - fields: In spec

Issue 4: Dynamic parallel processing

Status: open
Date added: 25 Jun 2003
Categories: Asynchronous operations
Origin: Initial requirements log, item 4 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Ivana Trickovic
Document: BPEL specification
Description:
BPEL only supports the invocation of a single web service within an invoke activity. In many situations it is required that a particular invoke activity results in the creation of many activity instances where the number of instances is not know at design time but is calculated at runtime from the contents of a set of data or references. All instances are carried out in parallel and must be synchronized for completion of the activity. Typical example for this type of processing is the sending of a request to a number of services. Processing of such an activity includes fanning out the requests, collecting the results of the requests, and determining the overall (combined) result of the different requests.
Qualifier: requirement
Links: Announcement, 25 Jun 2003     Yaron Y. Goland, 25 Mar 2004     Ivana Trickovic, 31 Mar 2004
Changes: 4 Jul 2003 - fields: Document;    31 Jul 2003 - fields: Champion;    25 Mar 2004 - fields: Links;    31 Mar 2004 - fields: Links;    2 Jun 2004 - fields: Champion

Issue 5: Suspend/resume

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Initial requirements log, item 5 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Document: BPEL specification
Description:
Sometimes it is necessary to suspend (halt) the execution of a business process for some time or until explicitly resumed by an appropriate action. The suspend/resume type of activities are mainly intended to be used in event handlers to suspend and resume the processing of either the complete business process or of a particular scope only.
Qualifier: requirement
Resolution: Proposed in Dieter Koenig1, 19 Jan 2004, decided 4 February 2004 con call

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

Status: open
Date added: 25 Jun 2003
Categories: Expressions, State management
Origin: Initial requirements log, item 6 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Document: BPEL specification
Description:
A set of parallel activities is treated as finished if all activities have been completed. In many cases the process does not need to wait for all the concurrent activities to finish for the overall objective to be reached. There should be a way to express the "completion" of the desired objective, causing termination of all "unnecessary" concurrent activities.
Qualifier: requirement
Proposed resolution: Satish Thatte, 17 Sep 2004
Links: Announcement, 25 Jun 2003     Yaron Y. Goland, 27 Aug 2004     Danny van der Rijn, 27 Aug 2004     andrew.francis@elf.mcgill.ca, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Edwin Khodabakchian, 28 Aug 2004     andrew.francis@elf.mcgill.ca, 28 Aug 2004     Satish Thatte, 31 Aug 2004     Alex Yiu, 1 Sep 2004     Ivana Trickovic, 1 Sep 2004     Axel Martens, 1 Sep 2004     Danny van der Rijn, 1 Sep 2004     Ivana Trickovic, 1 Sep 2004     Axel Martens, 1 Sep 2004     Danny van der Rijn, 1 Sep 2004     Francisco Curbera, 2 Sep 2004     Alex Yiu, 3 Sep 2004     Ivana Trickovic, 8 Sep 2004     Ivana Trickovic, 8 Sep 2004     Alex Yiu, 10 Sep 2004     Alex Yiu, 10 Sep 2004     Axel Martens, 10 Sep 2004     Axel Martens, 10 Sep 2004     Alex Yiu, 10 Sep 2004     , 11 Sep 2004     Ivana Trickovic, 11 Sep 2004     Ivana Trickovic, 11 Sep 2004     , 13 Sep 2004     Alex Yiu, 13 Sep 2004     Dieter Koenig1, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Ivana Trickovic, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Alex Yiu, 14 Sep 2004     Alex Yiu, 14 Sep 2004     Dieter Koenig1, 14 Sep 2004     Alex Yiu, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Dieter Koenig1, 14 Sep 2004     Axel Martens, 14 Sep 2004     Ivana Trickovic, 14 Sep 2004     Yaron Y. Goland, 16 Sep 2004     Danny van der Rijn, 16 Sep 2004     Proposed resolution (Satish Thatte, 17 Sep 2004)     Yaron Y. Goland, 17 Sep 2004     Danny van der Rijn, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Danny van der Rijn, 18 Sep 2004     Assaf Arkin, 18 Sep 2004     Frank Leymann, 19 Sep 2004     Satish Thatte, 19 Sep 2004     Frank Leymann, 19 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 20 Sep 2004     Danny van der Rijn, 20 Sep 2004     Satish Thatte, 20 Sep 2004     Peter Furniss, 21 Sep 2004     Yaron Y. Goland, 27 Sep 2004     Danny van der Rijn, 27 Sep 2004     Assaf Arkin, 28 Sep 2004     Proposal withdrawn, conf call 8 Dec 2004     Alex Yiu, 3 Sep 2004
Changes: 4 Jul 2003 - fields: Document;    27 Aug 2004 - fields: Links;    30 Aug 2004 - fields: Links;    31 Aug 2004 - fields: Links;    1 Sep 2004 - fields: Links;    2 Sep 2004 - fields: Links;    4 Sep 2004 - fields: Links;    8 Sep 2004 - fields: Links;    10 Sep 2004 - fields: Links;    11 Sep 2004 - fields: Links;    13 Sep 2004 - fields: Links;    14 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links;    18 Sep 2004 - fields: Status, Proposed resolution, Links;    20 Sep 2004 - fields: Links;    21 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    28 Sep 2004 - fields: Links;    8 Dec 2004 - fields: Status, Links;    20 Dec 2004 - fields: Links

Issue 7: Import

Status: resolved
In spec: 4 June 2004
Date added: 25 Jun 2003
Origin: Initial requirements log, item 7 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Francisco Curbera
Document: BPEL specification
Description:
Provide an import mechanism, just like WSDL, to include WSDL definitions and XSD schemas that a process is dependent on.
Qualifier: requirement
Resolution: Proposed in Francisco Curbera, 30 Sep 2003, with modifications in Kevin Liu, 1 Oct 2003, decided in meeting 15 October, with further modification, summarised in Francisco Curbera, 16 Oct 2003, later corrected

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:

For example:

	<bpel:import namespace="..."  location="document-location" importType="XYZ-namespace-uri"/>
A <bpel:import> location element will be interpreted as a hint for BPEL processors. In particular, processors are not required to retrieve the imported document from the specified location.
Links: Announcement, 25 Jun 2003     Discussed at meeting, 6 August (document details)     Francisco Curbera, 12 Sep 2003     Eckenfels. Bernd, 12 Sep 2003     Chris Keller, 12 Sep 2003     Francisco Curbera, 12 Sep 2003     Discussed at Redmond face-to-face     Proposed resolution (Francisco Curbera, 30 Sep 2003)     Yaron Goland, 30 Sep 2003     Kevin Liu, 1 Oct 2003     Francisco Curbera, 1 Oct 2003     Francisco Curbera, 1 Oct 2003     Approved resolution (Francisco Curbera, 16 Oct 2003)     Ivana Trickovic, 16 Oct 2003     Tony Fletcher, 20 Oct 2003     Ugo Corda, 20 Oct 2003     Danny van der Rijn, 20 Oct 2003     Yaron Goland, 20 Oct 2003
Changes: 4 Jul 2003 - fields: Document;    7 Aug 2003 - fields: Links;    10 Sep 2003 - fields: Champion;    12 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    1 Oct 2003 - fields: Status, Links, Proposed resolution, Vote announcement;    8 Oct 2003 - fields: Vote announcement;    15 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Resolution;    16 Oct 2003 - fields: Links, Resolution;    20 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    9 Jun 2004 - fields: In spec

Issue 8: Non-mutability of correlation sets

Status: resolved
In spec: No change
Date added: 25 Jun 2003
Categories: Correlation
Origin: Initial issue log, item 1 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Satish Thatte
Document: BPEL specification
Description:
The value of a correlation set once initialized is immutable, but this does not apply to the individual properties in the set, which may be shared with other sets. Thus the set should be thought of as a late-bound constant as a whole. The properties are just means of defining it. Questions: How much checking can be done at definition time and how much at execution time? Do we need a runtime fault?
Qualifier: clarification
Resolution: Proposed verbally by Satish Thatte and decided at San Francisco f-t-f

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

Status: resolution proposed
Date added: 25 Jun 2003
Categories: Syntax and validation
Origin: Initial issue log, item 2 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Document: BPEL specification
Description:
Static analysis is a well-established technique to support robust design and implementation practice. The specification permits that static analysis may reject a BPEL process definition, depending on how pessimistic the static analysis is. As a result, some BPEL definitions may not be portable between different BPEL implementations.

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

Status: resolved
In spec: 19 Nov 2004
Date added: 25 Jun 2003
Categories: Compensation
Origin: Initial issue log, item 3 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Dieter Roller
Document: BPEL specification
Description:
describe exactly how compensation handlers are invoked, including concurrency, especially in the case of default behavior.
Qualifier: clarification
Original resolution: Proposed in Satish Thatte, 20 Jun 2004, decided at San Francisco f-t-f

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

Revised resolution: Proposed in Satish Thatte, 8 Sep 2004, decided at conf call, 15 Sept 2004

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

Status: open
Date added: 25 Jun 2003
Categories: Data handling, Correlation
Origin: Initial issue log, item 4 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Danny van der Rijn
Document: BPEL specification
Description:
Is Assignment too restrictive? In particular, should it allow creation of nodes in cases where they are absent? There are situations where a process needs to construct a set of results. This requires using the query attribute in the <to-spec> to specify the next insertion location. Currently, the specification requires that the run time should throw a fault in these cases.
Proposed resolution: Alex Yiu, 4 Jan 2005
Links: Announcement, 25 Jun 2003     Danny van der Rijn, 6 Aug 2003     Yaron Goland, 6 Aug 2003     Yaron Goland, 6 Aug 2003     Glenn Mi, 6 Aug 2003     Chris Keller, 6 Aug 2003     Edwin Khodabakchian, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Edwin Khodabakchian, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Ugo Corda, 6 Aug 2003     Chris Keller, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     Chris Keller, 6 Aug 2003     Chris Keller, 6 Aug 2003     Ugo Corda, 6 Aug 2003     Danny van der Rijn, 6 Aug 2003     David RR Webber, 7 Aug 2003     Yaron Goland, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Harvey Reed, 7 Aug 2003     Yaron Goland, 8 Aug 2003     Yaron Goland, 8 Aug 2003     David RR Webber, 8 Aug 2003     Harvey Reed, 8 Aug 2003     Chris Keller, 8 Aug 2003     Danny van der Rijn, 8 Aug 2003     Yaron Goland, 8 Aug 2003     Danny van der Rijn, 8 Aug 2003     David RR Webber, 9 Aug 2003     Yaron Goland, 11 Aug 2003     David RR Webber, 12 Aug 2003     Danny van der Rijn, 12 Aug 2003     issue 48 : XML Transform Support     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Harvey Reed, 13 Aug 2003     Edwin Khodabakchian, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Chris Keller, 13 Aug 2003     Danny van der Rijn, 13 Aug 2003     Danny van der Rijn, 18 Aug 2003     Chris Keller, 19 Aug 2003     Tony Andrews, 20 Aug 2003     Danny van der Rijn, 20 Aug 2003     Yaron Goland, 20 Aug 2003     Harvey Reed, 20 Aug 2003     Greg Ritzinger, 29 Aug 2003     Ron Ten-Hove, 29 Aug 2003     David RR Webber, 30 Aug 2003     David RR Webber, 30 Aug 2003     David RR Webber, 1 Sep 2003     Chris Keller, 2 Sep 2003     David RR Webber, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Chris Keller, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     David RR Webber, 2 Sep 2003     Danny van der Rijn, 2 Sep 2003     Yaron Goland, 2 Sep 2003     Ron Ten-Hove, 2 Sep 2003     Ron Ten-Hove, 2 Sep 2003     Chris Keller, 2 Sep 2003     David RR Webber, 2 Sep 2003     David RR Webber, 3 Sep 2003     David RR Webber, 3 Sep 2003     Ron Ten-Hove, 30 Aug 2003     Ron Ten-Hove, 3 Sep 2003     David RR Webber, 3 Sep 2003     Danny van der Rijn, 3 Sep 2003     Satish Thatte, 4 Sep 2003     Chris Keller, 4 Sep 2003     Danny van der Rijn, 4 Sep 2003     Danny van der Rijn, 4 Sep 2003     Satish Thatte, 4 Sep 2003     David RR Webber, 5 Sep 2003     Chris Keller, 5 Sep 2003     Chris Keller, 5 Sep 2003     Monica Martin, 5 Sep 2003     Chris Keller, 5 Sep 2003     Monica Martin, 5 Sep 2003     Chris Keller, 5 Sep 2003     Danny van der Rijn, 5 Sep 2003     David RR Webber, 5 Sep 2003     David RR Webber, 5 Sep 2003     David RR Webber, 5 Sep 2003     Ugo Corda, 5 Sep 2003     Danny van der Rijn, 5 Sep 2003     Discussed at Redmond face-to-face     Danny van der Rijn, 3 Feb 2004     Edwin Khodabakchian, 3 Feb 2004     Pal Takacsi-Nagy, 3 Feb 2004     Edwin Khodabakchian, 3 Feb 2004     David RR Webber, 3 Feb 2004     Satish Thatte, 4 Feb 2004     Steve Capell, 4 Feb 2004     Alastair J. Green, 4 Feb 2004     David RR Webber, 4 Feb 2004     Peter Furniss, 4 Feb 2004     David RR Webber, 4 Feb 2004     Kristofer Agren, 5 Feb 2004     Danny van der Rijn, 13 Feb 2004     Monica J. Martin, 15 Feb 2004     David RR Webber, 15 Feb 2004     Diane Jordan, 16 Feb 2004     Diane Jordan, 16 Feb 2004     discussion and straw-poll, 18 Feb 2004 call     Danny van der Rijn, 18 Feb 2004     Danny van der Rijn, 18 Feb 2004     Glenn Mi, 19 Feb 2004     Danny van der Rijn, 19 Feb 2004     Danny van der Rijn, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     David RR Webber, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     David RR Webber, 23 Feb 2004     Kristofer Agren, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     Edwin Khodabakchian, 23 Feb 2004     Danny van der Rijn, 23 Feb 2004     Kristofer Agren, 23 Feb 2004     Alex Yiu, 23 Feb 2004     Danny van der Rijn, 24 Feb 2004     Alex Yiu, 24 Feb 2004     Alex Yiu, 26 Feb 2004     Yaron Y. Goland, 26 Feb 2004     David RR Webber, 26 Feb 2004     Edwin Khodabakchian, 26 Feb 2004     Monica J. Martin, 26 Feb 2004     Ron Ten-Hove, 26 Feb 2004     David RR Webber, 26 Feb 2004     Glenn Mi, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Glenn Mi, 27 Feb 2004     Chris Keller, 27 Feb 2004     Yaron Y. Goland, 27 Feb 2004     Ron Ten-Hove, 27 Feb 2004     David RR Webber, 27 Feb 2004     David RR Webber, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Chris Keller, 27 Feb 2004     Alex Yiu, 27 Feb 2004     Chris Keller, 27 Feb 2004     Alex Yiu, 28 Feb 2004     Monica J. Martin, 28 Feb 2004     Yaron Y. Goland, 1 Mar 2004     Alex Yiu, 2 Mar 2004     Danny van der Rijn, 2 Mar 2004     David RR Webber, 2 Mar 2004     Alex Yiu, 2 Mar 2004     Danny van der Rijn, 2 Mar 2004     Yaron Y. Goland, 2 Mar 2004     Edwin Khodabakchian, 3 Mar 2004     Alex Yiu, 3 Mar 2004     Ugo Corda, 3 Mar 2004     Alex Yiu, 3 Mar 2004     Kristofer Agren, 3 Mar 2004     David RR Webber, 3 Mar 2004     Ron Ten-Hove, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     David RR Webber, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     David RR Webber, 3 Mar 2004     David RR Webber, 16 Mar 2004     Danny van der Rijn, 25 Mar 2004     David RR Webber, 26 Mar 2004     Discussed at Walldorf f-t-f (document details)     discuessed on 28 April call (document details)     Peter Furniss, 5 May 2004     see rationale in issue 100     Proposed resolution (Alex Yiu, 4 Jan 2005)
Changes: 4 Jul 2003 - fields: Document;    7 Aug 2003 - fields: Links, Champion;    8 Aug 2003 - fields: Links;    9 Aug 2003 - fields: Links;    12 Aug 2003 - fields: Links;    13 Aug 2003 - fields: Links;    14 Aug 2003 - fields: Links;    19 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Links, Proposed resolution;    29 Aug 2003 - fields: Links;    30 Aug 2003 - fields: Links;    3 Sep 2003 - fields: Links;    4 Sep 2003 - fields: Links;    8 Sep 2003 - fields: Links;    18 Sep 2003 - fields: Links;    3 Feb 2004 - fields: Links;    4 Feb 2004 - fields: Links;    5 Feb 2004 - fields: Links;    16 Feb 2004 - fields: Links;    18 Feb 2004 - fields: Links;    19 Feb 2004 - fields: Links;    25 Feb 2004 - fields: Links;    26 Feb 2004 - fields: Links;    27 Feb 2004 - fields: Links;    28 Feb 2004 - fields: Links;    1 Mar 2004 - fields: Links;    3 Mar 2004 - fields: Links;    4 Mar 2004 - fields: Links;    16 Mar 2004 - fields: Links;    26 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution;    5 May 2004 - fields: Status, Resolution, Links;    6 May 2004 - fields: Links;    23 Jun 2004 - fields: Links;    13 Sep 2004 - fields: Categories;    5 Jan 2005 - fields: Links, Status, Proposed resolution

Issue 11.1: Making <assign> truly extensible

Status: resolution proposed
Date added: 5 Jan 2005
Date split: 5 January 2005
Categories: Data handling, Correlation
Submitter: Alex Yiu
Champion: Alex Yiu
Document: BPEL specification
Description:

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>

That implies we cannot have just one extended operation under the <assign> syntax. E.g.:
<assign>
    <foo:barOperation ... /> 
</assign>

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

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

Proposed Solution:

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

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

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

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

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

Related Schema Change: From:

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

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


Issue 12: XML types and WS Interactions

Status: resolution proposed
Date added: 25 Jun 2003
Categories: Data handling
Origin: Initial issue log, item 5 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Document: BPEL specification
Description:
The specification currently disallows use of variables defined using XML schema types and elements in Web service interactions. In cases where WSDL message types have single parts defined using compatible XML types and elements, it should be possible to use such variables in WS interactions.
Proposed resolution: Yaron Y. Goland, 10 Dec 2004 Ron Ten-Hove, 10 Dec 2004
Links: Announcement, 25 Jun 2003     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Yaron Y. Goland, 10 Dec 2004)     Ron Ten-Hove, 10 Dec 2004
Changes: 4 Jul 2003 - fields: Document;    22 Apr 2004 - fields: Links;    11 Dec 2004 - fields: Links, Status, Proposed resolution;    14 Dec 2004 - fields: Links

Issue 13: Future Usage of XPATH 2.0 and XQuery 1.0

Status: resolved
In spec: 4 June 2004
Date added: 25 Jun 2003
Origin: Initial issue log, item 6 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Francisco Curbera
Document: BPEL specification
Description:
The current specification mandates support for XPATH 1.0 and leaves the door open for other query and expression languages fir the future. XPATH 2.0 and XQuery 1.0 are the obvious future candidates. There are two related issues here.

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>
For example, an XPath 1.0 query would be encoded:
<wsbp:from variable="ncname" part="ncname"?>
  <wsbp:query>
  /shipNotice/ShipNoticeHeader/shipOrderID
  </wsbp:query>
</wsbp:from>
Conditions:
<wsbp:source ... >
      <wsbp:transitionCondition 
expressionLanguage=".."?>...</transitionCondition>?
</wsbp:source>
and
<wsbp:targets>
    <wsbp:joinCondition expressionLanguage="..."?>...</joinCondition> ?
     <wsbp:link.... />
</wsbp:targets>
.. the same for switch's case, and the whileCondition
Links: Yaron Y. Goland, 22 May 2003     Announcement, 25 Jun 2003     Proposed resolution (rkhalaf, 7 Dec 2003)     John Evdemon, 9 Dec 2003     Revised proposal (rkhalaf, 10 Dec 2003)     Assaf Arkin, 10 Dec 2003     Yaron Goland, 23 Dec 2003     Assaf Arkin, 23 Dec 2003     Yaron Goland, 23 Dec 2003     Assaf Arkin, 23 Dec 2003     Yaron Goland, 24 Dec 2003     Assaf Arkin, 7 Jan 2004     Yaron Goland, 7 Jan 2004     David RR Webber, 7 Jan 2004     Discussed at 7 January 2004 meeting - vote deferred for further input     Yaron Goland, 7 Jan 2004     David RR Webber, 7 Jan 2004     Assaf Arkin, 7 Jan 2004     David RR Webber, 7 Jan 2004     Assaf Arkin, 7 Jan 2004     David RR Webber, 7 Jan 2004     Assaf Arkin, 7 Jan 2004     David RR Webber, 7 Jan 2004     Alex Yiu, 7 Jan 2004     rkhalaf, 20 Jan 2004     Alex Yiu, 21 Jan 2004     Chris Keller, 3 Feb 2004     Yaron Goland, 3 Feb 2004     Dieter Koenig1, 22 Jul 2004     Yaron Y. Goland, 23 Jul 2004     Alex Yiu, 23 Jul 2004     Dieter Koenig1, 24 Jul 2004
Changes: 4 Jul 2003 - fields: Document;    10 Sep 2003 - fields: Champion;    8 Dec 2003 - fields: Links, Status, Proposed resolution;    10 Dec 2003 - fields: Links, Proposed resolution;    23 Dec 2003 - fields: Links;    7 Jan 2004 - fields: Links;    8 Jan 2004 - fields: Links;    21 Jan 2004 - fields: Links;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution;    3 Feb 2004 - fields: Links;    9 Jun 2004 - fields: In spec;    22 Jul 2004 - fields: Links;    23 Jul 2004 - fields: Links;    26 Jul 2004 - fields: Links

Issue 14: Restriction on join conditions

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Initial issue log, item 7 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Document: BPEL specification
Description:
Should join conditions be restricted to be monotonic? This relates to some related research at York University http://www.cs.yorku.ca/techreports/2003/CS-2003-04.html and seems to essentially say that it is undesirable to allow join conditions that evaluate to true because a link status is false.
Resolution: Proposed in Dieter Koenig1, 19 Jan 2004, decided 4 February 2004 con call

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

Status: resolved
In spec: No change
Date added: 25 Jun 2003
Categories: Related standards
Origin: Initial issue log, item 8 (document details )
Date submitted: 23 May 2003
Submitter: Original authors group
Champion: Francisco Curbera
Document: BPEL specification
Description:
Tracking: WSDL 1.2 has a number of MEPs. We need to clarify the relationship of these with BPEL.
Resolution: Proposed in Yaron Y. Goland, 16 Sep 2004, decided at September face-to-face

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Mike Marin, 22 May 2003 - issue "a" from that message
Date submitted: 22 May 2003
Submitter: Mike Marin, Filenet
Document: BPEL specification
Description:
We don't have distributed transactions on web services yet. So how do we insure that an activity such as an "invoke" is executed exactly one time? The following example illustrates the problem:
1. Process A begins execution of an invoke instruction, and sends an input message to Process B. There is no output message defined on the invoke.
2. Process B is defined with a receive instruction corresponding to the invoke of process A, and the receive instruction creates a new instance of the process. So upon receipt of the message from process A, a new instance of process B is created, and this instance executes the receive instruction.
3. The machine hosting process A crashes.
4. Process B executes the next step, which is to debit an account and update a database.
5. Process B terminates. Process B has finished.
6. The machine hosting process A is restarted. Process A then re-executes the invoke instruction.

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Mike Marin, 22 May 2003 - issue "b" from that message
Date submitted: 22 May 2003
Submitter: Mike Marin, Filenet
Document: BPEL specification
Description:
Invoking an operation, with input and output, that is implemented by a process using receive and replay requires the WSDL operation to be asynchronous. A process may take days or weeks between the receive and the reply, so the client cannot keep a connection open waiting for the reply. Although WSDL 1.1 talks about asynchronous operations; it does not seems to be any support for it in the WSDL specification.
Resolution: Proposed in Yaron Goland, 20 Jan 2004, decided at conf call, 21 January 2004

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email David Burdett, 22 May 2003
Date submitted: 22 May 2003
Submitter: David Burdett, CommerceOne
Document: BPEL specification
Description:
THE PROBLEM The problem arises because of three assumptions that I believe are valid:
1. BPEL is an "execution only" language, i.e. it is desgined to be something that can be input into software and run, e.g. using some "BPEL Run Time" software
2. BPEL will often be defined and maintained with the aid of some GUI based "BPEL Design Time" software that allows the process to be visualised.
3. The BPEL Design Time software will contain additional positional and graphical information about the visual representation of the BPEL design that not contained in the BPEL XML definitions.

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Fred Carter, 22 May 2003
Date submitted: 22 May 2003
Submitter: Fred Carter, Amberpoint
Document: BPEL specification
Description:
BPEL introduces the notion of properties & property aliases. This combination provides powerful expressive capabilities for "important concepts" to a process. This information is expected, at present, to be distributed between the BPEL definition (the properties) and the WSDL definitions (the property aliases).

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Ram Jeyaraman, 28 May 2003
Date submitted: 28 May 2003
Submitter: Ram Jeyaraman, Sun
Champion: Ram Jeyaraman
Document: BPEL specification
Description:
should a faulted scope be deemed successfully completed or not?

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

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Categories: Fault handling, Syntax and validation
Origin: Extracted from email Edwin Khodabakchian, 29 May 2003
Date submitted: 29 May 2003
Submitter: Edwin Khodabakchian, Collaxa
Document: BPEL specification
Description:
Given that faultHandlers/catch are not expected to do any forward looking work, I would like to suggest that we consider renaming them to cancellationHandlers/catch.
Resolution: Proposed in Satish Thatte, 18 Feb 2004, decided at conference call 3 March 2004

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.

Links: Announcement, 25 Jun 2003     Edwin Khodabakchian, 18 Feb 2004     Proposed resolution (Satish Thatte, 18 Feb 2004)
Changes: 4 Jul 2003 - fields: Document;    18 Feb 2004 - fields: Links, Status, Proposed resolution;    3 Mar 2004 - fields: Status, Proposed resolution, Resolution, Rationale

Issue 22: Implicit <sequence> macro

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Yuzo Fujishima, 11 Jun 2003
Date submitted: 11 June 2003
Submitter: Yuzo Fujishima, NEC Corporation
Champion: Yuzo Fujishima
Document: BPEL specification
Description:
I would like to propose what may be called "implicit sequence". Implicit sequence "macro": If multiple activities are placed in a process definition where only one activity is allowed per se, assume there is an implicit sequence activity that contains the activities. Example: Regard
  <scope>
   <receive/>
   <invoke/>
   <reply/>
  </scope>
as
  <scope>
   <sequence>     <!-- implicit sequence -->
    <receive/>
    <invoke/>
    <reply/>
   </sequence>
  </scope>

Resolution: Proposed in Yaron Goland, 19 Jan 2004, decided 4 February 2004 con call

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

Status: resolved
In spec: 4 June 2004
Date added: 25 Jun 2003
Origin: Extracted from email Eckenfels. Bernd, 12 Jun 2003
Date submitted: 12 June 2003
Submitter: Bernd Eckenfels, Seeburger
Previous title: implicit links of the runtime engine
Champion: Bernd Eckenfels
Document: BPEL specification
Description:
The spec contains a <sequence> construct, which totally can be replaced by a <flow> with explicit links between contained activities.

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


Links: Eckenfels. Bernd, 12 Jun 2003     Assaf Arkin, 12 Jun 2003     Eckenfels. Bernd, 13 Jun 2003     Satish Thatte, 13 Jun 2003     Assaf Arkin, 13 Jun 2003     Satish Thatte, 14 Jun 2003     Assaf Arkin, 16 Jun 2003     Satish Thatte, 16 Jun 2003     Assaf Arkin, 16 Jun 2003     Satish Thatte, 16 Jun 2003     Eckenfels. Bernd, 17 Jun 2003     Assaf Arkin, 17 Jun 2003     Ron Ten-Hove, 17 Jun 2003     Fred Carter, 17 Jun 2003     Ron Ten-Hove, 17 Jun 2003     Maciej Szefler, 18 Jun 2003     Satish Thatte, 19 Jun 2003     Fred Carter, 19 Jun 2003     Assaf Arkin, 19 Jun 2003     Ron Ten-Hove, 20 Jun 2003     Eckenfels. Bernd, 20 Jun 2003     Satish Thatte, 20 Jun 2003     David RR Webber, 20 Jun 2003     Assaf Arkin, 20 Jun 2003     Assaf Arkin, 20 Jun 2003     David RR Webber, 20 Jun 2003     Assaf Arkin, 20 Jun 2003     Ugo Corda, 20 Jun 2003     David RR Webber, 20 Jun 2003     Announcement, 25 Jun 2003     Eckenfels. Bernd, 25 Jun 2003     Ram Jeyaraman, 28 Jul 2003     Assaf Arkin, 30 Jul 2003     Eckenfels. Bernd, 18 Aug 2003     Yaron Goland, 19 Aug 2003     Eckenfels. Bernd, 19 Aug 2003     Eckenfels. Bernd, 20 Aug 2003     Monica Martin, 24 Aug 2003     Eckenfels. Bernd, 25 Aug 2003     Proposed resolution (Neelakantan Kartha, 29 Aug 2003)
Changes: 4 Jul 2003 - fields: Document, Links;    29 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    18 Aug 2003 - fields: Links;    19 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Links;    25 Aug 2003 - fields: Links;    30 Aug 2003 - fields: Links;    1 Oct 2003 - fields: Status, Proposed resolution, Vote announcement;    6 Oct 2003 - fields: Status, Vote announcement;    9 Oct 2003 - fields: Status, Proposed resolution, Vote announcement, Resolution;    15 Oct 2003 - fields: Resolution;    9 Jun 2004 - fields: In spec

Issue 24: Separate schemas for executable vs abstract BPEL

Status: resolved
In spec: no change
Date added: 25 Jun 2003
Origin: Extracted from email Danny van der Rijn, 12 Jun 2003
Date submitted: 12 June 2003
Submitter: Danny van der Rijn, Tibco
Champion: Sumeet S Malhotra
Document: BPEL specification
Description:
Separate schemas for the executable vs. the abstract forms of BPEL would allow validation by schema, rather than by hand-coded rules based on spec verbiage.

Resolution: Proposed in Danny van der Rijn, 7 Jan 2004, decided 4 February 2004 con call

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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Jun 2003
Categories: Compensation, Process coordination
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
What are the semantics of a compensation handler specified for the business process as a whole when the enableInstanceCompensation attribute is set to "no"? If instance compensation is not enabled then it should be an error to define a compensation handler. This should be clarified. If the intent is to disable default compensation when no compensation handler is defined then another alternative is to assume that no compensation is possible if no compensation handler is defined (and the same for scopes). A default compensation handler would take the form of:
<compensationHandler>
  <compensate/>
</compensationHandler>
Although this require more XML elements to be defined, it allows the compensation handling behavior to be turned on and off for the process and a scope by simply electing not to define a compensation handler. At any rate, the ability to disable compensation for a scope is also required if a process attempts to invoke compensation handlers for invoked services from compensation handlers associated with the invoke activity's scope.
Qualifier: clarification, enhancement
Resolution: Proposed in Yaron Y. Goland, 31 Mar 2004, decided by Web ballot (ended 28 Apr 2004) , after straw poll at Walldorf ftf

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

Status: open
Date added: 26 Jun 2003
Categories: Correlation
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
"Two outstanding synchronous requests from a specific partner link for a particular operation and correlation set(s) cannot be outstanding simultaneously". A reply activity need only identify the partnerLink and operation, and therefore cannot determine which request it responds to.
Qualifier: clarification
Links: Announcement, 26 Jun 2003     Danny van der Rijn, 5 Sep 2003     Monica Martin, 25 Sep 2003     Danny van der Rijn, 25 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    8 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links

Issue 27: Setting link status in case of transition condition

Status: resolved
In spec: 4 June 2004
Date added: 26 Jun 2003
Categories: operational semantic
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
Consider the following example:

<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

Status: open
Date added: 26 Jun 2003
Categories: Expressions, State management
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
The specification uses the XPath language to define join conditions where in fact join conditions could only use a subset of the XPath language. Furthermore, it places a constraint that the expression use the getLinkStatus function with the name of an input link. The issue arises from the complexity of analyzing an XPath expression to determine the proper usage of XPath expressions. If the intent is not to use the full power of the XPath language and validation of the expression cannot be performed by an XPath library, perhaps we can propose a more restrictive and simpler syntax.
Qualifier: enhancement
Links: Announcement, 26 Jun 2003     Satish Thatte, 15 Sep 2003     Assaf Arkin, 20 Oct 2003
Changes: 4 Jul 2003 - fields: Origin, Links;    31 Jul 2003 - fields: Champion;    15 Sep 2003 - fields: Links;    20 Oct 2003 - fields: Links

Issue 29: Simplification of XPath expressions

Status: open
Date added: 26 Jun 2003
Categories: Expressions
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
Consider the following expression:

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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Jun 2003
Categories: Process coordination
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
Support for use of coordination protocols for invoking services by process and when process invoked by another service.

Clarify use of coordination protocol to:

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

Status: resolved
In spec: No change
Date added: 26 Jun 2003
Categories: Correlation
Origin: Email direct to issue editor
Date submitted: 25 June 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description:
A process needs to send a message and receive one or more respones asynchronously that are correlated and needs to use the correlation mechanism. The process is started with a request that contains values which are not known to be unique. There is a risk that using one of these values would result in the condition whereby a response is correlated to two or more processes. There needs to be a mechanism by which the process can decide on a unique value for the purpose of instantiating a correlation set.

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

Status: resolved
In spec: 4 June 2004
Date added: 3 Jul 2003
Origin: Yuzo Fujishima, 2 Jul 2003
Date submitted: 02 July 2003
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: BPEL specification
Description: According to 13.5.4.2 Message Events, BPEL 1.1 allows one event handler activity to run concurrently. However, it is not specified whether all concurrent "threads" share link status or each thread maintains its own link status. Suppose activity B has synchronization dependency on A. Can B in a thread be run after A is completed in other thread? Or only after A is completed in the same thread?
Resolution: Proposed in message Yuzo Fujishima, 27 Sep 2003, decided in TC conf call, 1 October 2003

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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 9 Jul 2003
Categories: Correlation
Date submitted: 07 July 2003
Submitter: Eckenfels. Bernd
Champion: Bernd Eckenfels
Document: BPEL specification (Sample on p.22, version 1.1)
Description: Current specification does not address implementation semantics for registering correlations

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

Status: resolved
In spec: 16 Aug 2004
Date added: 9 Jul 2003
Categories: Related standards, Partner links
Date submitted: 09 July 2003
Submitter: Ron Ten-Hove
Champion: Ron Ten-Hove
Document: BPEL specification
Description: BPEL4WS incorporates WS-Addressing, which is a proprietary specification. This is inappropriate for an open standard.
Vote: yes=19, no=3, abstain=3, at San Francisco f-t-f
Proposed resolution: Ron Ten-Hove, 7 May 2004
Resolution: Proposed in Alex Yiu, 21 Jun 2004, modified and decided at San Francisco f-t-f

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

Status: resolved
In spec: no change
Date added: 9 Jul 2003
Date submitted: 09 July 2003
Submitter: Assaf Arkin
Champion: Sumeet S Malhotra
Description: The current specification suggests that BPEL is targeting execution of processes and exchange of business protocol definitions. It would be beneficial if the language could also be used to address certain aspects of modeling, such that it can leverage tooling support to bridge the gap between modeling, design, exceuting and monitoring.

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

Status: resolved
In spec: 4 June 2004
Date added: 9 Jul 2003
Date submitted: 09 July 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description: An onMessage event handler is written to receive some input message (as identified by the operation), assign it to some variable and then perform some work based on the content of that message.

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

Status: resolved
In spec: 1.35, 30 June 2004
Date added: 11 Jul 2003
Categories: Correlation
Date submitted: 11 July 2003
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: BPEL specification
Description:

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.

Affected Sections:


Links: Announcement, 11 Jul 2003     Satish Thatte, 11 Aug 2003     Satish Thatte, 11 Aug 2003     Discussed at Redmond face-to-face     Yuzo Fujishima, 27 Sep 2003     Satish Thatte, 13 Oct 2003     Yuzo Fujishima, 14 Oct 2003     Satish Thatte, 14 Oct 2003     Eckenfels. Bernd, 14 Oct 2003     Satish Thatte, 14 Oct 2003     Eckenfels. Bernd, 16 Oct 2003     Ugo Corda, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Ugo Corda, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Ugo Corda, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Ugo Corda, 17 Oct 2003     Satish Thatte, 17 Oct 2003     Yaron Goland, 20 Oct 2003     Satish Thatte, 20 Oct 2003     Yaron Goland, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Proposed resolution (Yuzo Fujishima, 10 Mar 2004)     Eckenfels. Bernd, 10 Mar 2004     Yuzo Fujishima, 11 Mar 2004     Ugo Corda, 11 Mar 2004     Yuzo Fujishima, 11 Mar 2004     Ugo Corda, 11 Mar 2004     Yuzo Fujishima, 12 Mar 2004     Ugo Corda, 12 Mar 2004     Yaron Y. Goland, 12 Mar 2004     Alex Yiu, 17 Mar 2004     Satish Thatte, 17 Mar 2004     Proposed resolution - revised (Yuzo Fujishima, 17 Mar 2004)     Monica J. Martin, 17 Mar 2004     Yaron Y. Goland, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Yaron Y. Goland, 19 Mar 2004     Yuzo Fujishima, 25 Mar 2004     Discussed at 14 April con call (document details)     Alex Yiu, 28 Apr 2004     Yuzo Fujishima, 28 Apr 2004     Satish Thatte, 28 Apr 2004     Alex Yiu, 2 May 2004     Satish Thatte, 2 May 2004     Alex Yiu, 3 May 2004     Satish Thatte, 4 May 2004     Alex Yiu, 4 May 2004     Yaron Y. Goland, 6 May 2004     Satish Thatte, 6 May 2004     Goran Olsson, 6 May 2004     Satish Thatte, 6 May 2004     Alex Yiu, 12 May 2004     Revised proposal (Alex Yiu, 15 Jun 2004)     Upload of revised proposal (Alex Yiu, 15 Jun 2004)     Peter Furniss, 16 Jun 2004     Satish Thatte, 16 Jun 2004     Peter Furniss, 16 Jun 2004     Alex Yiu, 16 Jun 2004     Assaf Arkin, 18 Jun 2004     Satish Thatte, 18 Jun 2004     Peter Furniss, 18 Jun 2004     Francisco Curbera, 18 Jun 2004     Satish Thatte, 18 Jun 2004     Alex Yiu, 18 Jun 2004     Francisco Curbera, 19 Jun 2004     Satish Thatte, 19 Jun 2004     Francisco Curbera, 20 Jun 2004     Alex Yiu, 21 Jun 2004     Issue_37_Proposal_Draft.html (document details)     Revised proposal (Alex Yiu, 21 Jun 2004)     Resend of revised proposal (Satish Thatte, 21 Jun 2004)     Resend of revised proposal (Satish Thatte, 21 Jun 2004)     Proposed resolution (Francisco Curbera, 23 Jun 2004)     Alex Yiu, 23 Jun 2004     Issue_37_Proposal_Draft_simplified.html (document details)     Proposed resolution (Alex Yiu, 23 Jun 2004)
Changes: 11 Jul 2003 - new issue;    11 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    12 Aug 2003 - fields: Links;    18 Sep 2003 - fields: Links;    27 Sep 2003 - fields: Links;    13 Oct 2003 - fields: Links;    14 Oct 2003 - fields: Links;    16 Oct 2003 - fields: Links;    17 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    10 Mar 2004 - fields: Links, Status, Proposed resolution;    11 Mar 2004 - fields: Links;    13 Mar 2004 - fields: Links;    17 Mar 2004 - fields: Links;    19 Mar 2004 - fields: Links;    20 Mar 2004 - fields: Links;    25 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    3 May 2004 - fields: Links;    4 May 2004 - fields: Links;    5 May 2004 - fields: Links;    6 May 2004 - fields: Links;    7 May 2004 - fields: Links;    12 May 2004 - fields: Links;    16 Jun 2004 - fields: Proposed resolution, Links;    17 Jun 2004 - fields: Links;    18 Jun 2004 - fields: Links;    19 Jun 2004 - fields: Links;    20 Jun 2004 - fields: Links;    21 Jun 2004 - fields: Proposed resolution, Links;    22 Jun 2004 - fields: Links;    23 Jun 2004 - fields: Links, Status, Proposed resolution;    24 Jun 2004 - fields: Status, Proposed resolution, Resolution;    15 Jul 2004 - fields: In spec

Issue 38: Directed Activity Graph and block structured

Status: resolved
In spec: no change
Date added: 13 Jul 2003
Date submitted: 09 July 2003
Submitter: Assaf Arkin
Champion: Assaf Arkin
Document: BPEL specification
Description: The current specification provides a syntax that combines both DAG and block structured constructs. This leads to some redundancy, since some block structured constructs are not necessary given the alternative way to represent them using the <flow> activity and links.

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

Status: resolved
In spec: 4 June 2004
Date added: 16 Jul 2003
Date submitted: 16 July 2003
Submitter: Ugo Corda
Champion: Ugo Corda
Document: BPEL specification (document details )
Description: It looks like the syntax for query attribute values is inconsistent throughout the examples presented in the spec.

On page 38:

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

On page 49:

<bpws:propertyAlias propertyName="cor:customerID" 
        messageType="tns:POMessage" part="PO" 
        query="/PO/CID"/> 
(and similarly the three following propertyAlias elements in the same example)

On page 92:

<bpws:propertyAlias propertyName="tns:shipOrderID" 
        messageType="sns:shippingNoticeMsg" 
        part="shipNotice" 
        query="/ShipNoticeHeader/shipOrderID"/> 
instead of query="/shipNotice/ShipNoticeHeader/shipOrderID" (and similarly the four following propertyAlias elements in the same example)

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."
and sec. 8.2, Defining Properties, says:
"The interpretation of the message, part, and query attributes is the same as in the corresponding from-spec in copy assignments (see Assignment).

Resolution: decided in TC conf call, 20 August 2003
See text in message Ugo Corda, 18 Aug 2003

Links: Ugo Corda, 12 Jul 2003     Announcement, 16 Jul 2003     Ugo Corda, 31 Jul 2003     Edwin Khodabakchian, 31 Jul 2003     Ugo Corda, 31 Jul 2003     Eckenfels. Bernd, 31 Jul 2003     Ugo Corda, 31 Jul 2003     Ugo Corda, 31 Jul 2003     Glenn Mi, 31 Jul 2003     Kevin Liu, 31 Jul 2003     Ugo Corda, 31 Jul 2003     Ugo Corda, 31 Jul 2003     Ugo Corda, 1 Aug 2003     Diane Jordan, 1 Aug 2003     Kevin Liu, 4 Aug 2003     Ugo Corda, 4 Aug 2003     Danny van der Rijn, 4 Aug 2003     Monica Martin, 5 Aug 2003     Discussed at meeting, 6 August (document details)     Ugo Corda, 18 Aug 2003
Changes: 16 Jul 2003 - new issue;    20 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Champion;    31 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Links;    31 Jul 2003 - fields: Links;    1 Aug 2003 - fields: Links;    3 Aug 2003 - fields: Links;    5 Aug 2003 - fields: Links;    7 Aug 2003 - fields: Links;    18 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Status, Resolution;    9 Jun 2004 - fields: In spec

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

Status: resolved
In spec: no change
Date added: 24 Jul 2003
Date submitted: 24 July 2003
Submitter: Peter Furniss
Description: On invoke, reply etc. using the name "variable" for the attribute that defines which variable holds the sent or received message doesn't seem very obvious. Wouldn’t it be clearer to rename the “variable” attribute to be “message” (with “inputMessage”, “outputMessage” on invoke)?
Qualifier: minor
Resolution: Proposed in Yaron Goland, 19 Jan 2004, decided 4 February 2004 con call

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

Status: resolved
In spec: 4 June 2004
Date added: 31 Jul 2003
Categories: Event Handling, Syntax and validation, Specification editing
Date submitted: 30 July 2003
Submitter: Ram Jeyaraman
Champion: Ram Jeyaraman
Document: BPEL specification (page 25, version 1.1)
Description: The onMessage definition (part of eventHandlers), is missing a cardinality symbol "*". Refer to page 80 for a correct definition.
Qualifier: typo
Resolution: Proposed in message Ram Jeyaraman, 21 Sep 2003, decided in TC conf call, 1 October 2003

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

Status: resolved
In spec: no change
Date added: 31 Jul 2003
Categories: Technology concepts
Date submitted: 31 July 2003
Submitter: Sid Askary
Description: There is a need for formalism. It will allow us to not only reason about the current specification and related issues, but also uncover issues that would otherwise go unnoticed. Empirical deduction is not sufficient. Other efforts have begun to formalize their language (i.e. XQUERY).
Revisitable: yes
Resolution: Proposed in Peter Furniss, 20 Feb 2004, decided at conference call 3 March 2004

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

Status: resolved
In spec: 16 Aug 2004
Date added: 31 Jul 2003
Categories: State management
Date submitted: 30 July 2003
Submitter: Ram Jeyaraman
Champion: Ram Jeyaraman
Description: The current spec does not provide for specifying periodicity of an alarm event. One can conceive of a periodic alarm that is used, for example, in process state monitoring, etc.
<onAlarm for="duration-expr"?
     until="deadline-expr"?
     repeat="duration-expr"?
     frequency="cardinal-expr"?>*
         alarmActivity
</onAlarm>

Resolution: Proposed in Yaron Y. Goland, 16 Jun 2004, decided at San Francisco f-t-f

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>
repeatEvery can appear on its own, or with one of the other two attributes. If on its own, the semantics of repeatEvery are that from the time that the event handler is instantiated until it is un-instantiated an event handler will be created every duration-expr period. Like onEvent handlers each onAlarm handler created as a consequence of a repeatEvery exists independently of all other instances.

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

Status: resolved
In spec: 16 Aug 2004
Reopened: By decision of TC conf call meeting, 29 Oct 2003 (document details)
Date added: 5 Aug 2003
Categories: Syntax and validation, Intra-process messages, Correlation
Date submitted: 01 August 2003
Submitter: Marin, Mike
Description: The Invoke activity requires a partnerLink and a portType. However the partnerLink refers to a partnerLinkType, which also includes the portType. Therefore the portType in the Invoke is redundant.

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


Resolution: Proposed in Yaron Y. Goland, 4 Jun 2004, decided at San Francisco f-t-f

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

Status: resolved
In spec: 4 June 2004
Date added: 7 Aug 2003
Date submitted: 06 August 2003
Submitter: Danny van der Rijn
Champion: Danny van der Rijn
Document: BPEL specification
Description: In section 12.3, the "while" activity is described as follows:

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

Resolution: decided in TC conf call, 20 August 2003
To be referred to the editorial committee.

Links: Announcement, 7 Aug 2003     Danny van der Rijn, 7 Aug 2003     Harvey Reed, 7 Aug 2003     Eckenfels. Bernd, 9 Aug 2003
Changes: 7 Aug 2003 - new issue;    7 Aug 2003 - fields: Links;    8 Aug 2003 - fields: Links, Champion;    9 Aug 2003 - fields: Links;    20 Aug 2003 - fields: Status, Resolution;    9 Jun 2004 - fields: In spec

Issue 46: Namespace for the document fragment representing a part

Status: resolved
In spec: 4 June 2004
Date added: 7 Aug 2003
Date submitted: 07 August 2003
Submitter: Chris Keller
Description: The document fragment for a message part declared as a type in a query attribute, when treated as suggested in issue 39 : Inconsistent syntax for query attribute values in spec examples , requires specification of the namespace in the xpath below part name in the query. Further for XPath 1.0 compliance, all elements that have a namespace should be qualified.

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.

Links: issue 39 : Inconsistent syntax for query attribute values in spec examples     Ugo Corda, 7 Aug 2003     Chris Keller, 7 Aug 2003     Announcement, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Chris Keller, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Chris Keller, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Sanjiva Weerawarana, 7 Aug 2003     Sanjiva Weerawarana, 7 Aug 2003     David RR Webber, 7 Aug 2003     Ugo Corda, 7 Aug 2003     Sanjiva Weerawarana, 7 Aug 2003     David RR Webber, 7 Aug 2003     David RR Webber, 7 Aug 2003     Sanjiva Weerawarana, 8 Aug 2003     David RR Webber, 8 Aug 2003     Chris Keller, 8 Aug 2003     Sanjiva Weerawarana, 8 Aug 2003     David RR Webber, 8 Aug 2003     John Evdemon, 8 Aug 2003     David RR Webber, 8 Aug 2003     Discussed at Redmond face-to-face     Proposed resolution (Francisco Curbera, 24 Sep 2003)
Changes: 7 Aug 2003 - new issue;    7 Aug 2003 - fields: Links, description corrected from original announcement;    8 Aug 2003 - fields: Links;    18 Sep 2003 - fields: Links;    25 Sep 2003 - fields: Links;    30 Sep 2003 - fields: Proposed resolution, Status;    1 Oct 2003 - fields: Vote announcement;    8 Oct 2003 - fields: Vote announcement;    15 Oct 2003 - fields: Status, Vote announcement, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 47: Which Version of WSDL should we use?

Status: resolved
In spec: no change
Date added: 8 Aug 2003
Date submitted: 07 August 2003
Submitter: Liu, Kevin
Document: BPEL specification
Description: The BPEL4WS 1.1 draft uses WSDL1.1. Given the time the draft was created, it's very reasonable that WSDL1.1 was used. As time elapses and WSDL1.2 is about to emerge, it may be the time for us to reconsider which version of WSDL should BPEL 1.2 (or whatever number we choose to version our deliverable) be based on. The decision may have significant impact on our workload and maybe schedule.

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

Status: resolved
In spec: no change
Date added: 12 Aug 2003
Categories: Data handling, Expressions
Date submitted: 12 August 2003
Submitter: Yaron Goland
Document: BPEL specification
Description: How should BPEL support XML transformations? For example, we could make it possible to include a XSLT or XQUERY transform in a BPEL.
Resolution: Proposed in Yaron Y. Goland, 25 Mar 2004, decided by Web ballot (ended 28 Apr 2004)

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

Status: resolved
In spec: no change
Date added: 12 Aug 2003
Date submitted: 12 August 2003
Submitter: Danny van der Rijn
Description: Imagine a process that has more than one <receive> outstanding on a particular partnerLink/porttype/operation. There is currently no way to tell which one to <reply> to when a <reply> is encountered.
Resolution: Proposed in Danny van der Rijn, 14 Jan 2004, decided at conf call, 21 January 2004

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"

Status: resolved
In spec: 4 June 2004
Date added: 12 Aug 2003
Date submitted: 12 August 2003
Submitter: Danny van der Rijn
Description: Should WSBPEL make explicit the semantics for a <receive> that has no matching <reply> at run-time?
Resolution: proposed in Dieter Roller, 25 Nov 2003, agreed at Melbourne face-to-face, 10 December 2003

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.

Links: Announcement, 12 Aug 2003     Proposed resolution (Dieter Roller, 25 Nov 2003)
Changes: 12 Aug 2003 - new issue;    12 Aug 2003 - fields: Links;    25 Nov 2003 - fields: Links, Status, Proposed resolution;    10 Dec 2003 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 51: Section 9.3.1 & Schema Validation

Status: open
Date added: 18 Aug 2003
Categories: Data handling, Expressions
Date submitted: 18 August 2003
Submitter: Yaron Goland
Document: BPEL specification
Description: Section 9.3.1 specifies a design where to copy from one variable to another the schema of the source must either be identical to or a sub-set of the schema of the destination. This makes it impossible to do such things as use a scratch variable with the schema <ANY> as a source even if its contents are valid against the schema of the destination. This email contains a description of the problem and a proposal for a solution.
Links: Yaron Goland, 8 Aug 2003     Announcement, 18 Aug 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Discussed at Walldorf f-t-f (document details)     see rationale in issue 100     Dieter Koenig1, 24 Nov 2004
Changes: 18 Aug 2003 - new issue;    18 Aug 2003 - fields: Links;    15 Jan 2004 - fields: Links;    22 Apr 2004 - fields: Links;    23 Jun 2004 - fields: Links;    25 Nov 2004 - fields: Links

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

Status: resolved
In spec: No change
Date added: 18 Aug 2003
Categories: Intra-process messages, Correlation
Date submitted: 18 August 2003
Submitter: Yaron Goland
Document: BPEL specification
Description: Should BPEL provide a standard way to specify how flows in the same process send messages to each other? It is possible and critical that flows in the same process be able to send messages to each other but there is no standard way to specify that this is happening in a BPEL process definition.
Original title: Should BPEL provide a standard way to specify how flows in the same process send messages to each other?
Resolution: proposed in Dieter Koenig1, 17 Sep 2004, agreed at f-t-f, 22 Sept 2004

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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue A
Date submitted: 26 August 2003
Submitter: Alastair Green
Champion: Peter Furniss
Description: There are three multi-vendor specifications which address the needs of business transaction management for Web Services: Business Transaction Protocol 1.0 (OASIS Committee Specification, June 2002); WS-Transaction (proprietary consortium, August 2002), and the very recently published WS-TXM (proprietary consortium, August 2003).

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.
These facilities are all portable over products implementing WS-T BA, BTP and WS-TXM outcome protocols.

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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue B
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: A mechanism is needed to hold business transaction contexts and participant identifications.
Revisitable: Yes
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     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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue C
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: Constructs are needed to specify how business transaction contexts are transmitted and received with the application messages sent and received via invoke, receive, reply etc.
Revisitable: Yes
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     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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue D
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: Constructs are needed to specify how a business transaction is initiated. This will cause the creation of a new, propagatable context value.
Revisitable: Yes
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     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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue E
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: Constructs are needed to specify how a BPEL process requests the termination (completion) of a business transaction. The process needs to be able to specify that completion is negative (cancelled/compensated/undone) or positive (confirmed).
Revisitable: Yes
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     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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue F
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: BTM termination constructs (see issue 57) should allow the selection of registered participants, such that some can be confirmed, some cancelled
Revisitable: Yes
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     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

Status: resolved
In spec: 1.34, 19 June 2004
Date added: 26 Aug 2003
Categories: Process coordination
Origin: Choreology submission on business transaction management (document details), issue G
Date submitted: 26 August 2003
Submitter: Peter Furniss
Champion: Peter Furniss
Description: Constructs are needed to allow a BPEL process to register as a participant in a business transaction, such that the work of the process is confirmed or cancelled in reaction to the appropriate business transaction protocol messages
Revisitable: Yes
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     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

Status: resolved
In spec: no change
Date added: 8 Sep 2003
Date submitted: 04 September 2003 For the purposes of internal process execution management and administration of services, one is forced to imagine some property of the process that would identify it with a category. Such internal classification is common practice and can be reflected explicitly:

<process  name="ncname" targetNamespace="uri"
   queryLanguage="anyURI"?
   .
   .
   category="ncname"/>
 
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 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

Status: resolved
In spec: no change
Date added: 8 Sep 2003
Date submitted: 04 September 2003 Since we are dealing with an execution language, the question of runtime priority comes to mind. One could imagine an additional process property. While there may be other methods, this could explicitly be expressed as an additional binary attribute to the process element followed, conditionally, by a new element.

a)

<process  name="ncname" targetNamespace="uri"
	queryLanguage="anyURI"?
	.
	.
	prioritize="yes|no"?/>
b)
<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

Status: resolved
In spec: 4 June 2004
Date added: 12 Sep 2003
Date submitted: 12 September 2003
Submitter: Dieter Roller
Description: The specification does not specify exactly the rules that apply for scopes within event handlers and the following behavior is suggested.

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"

Related issue: issue 79 : Serializable scopes do not need to be leaf scopes
Resolution: proposed in Dieter Roller, 29 Nov 2003, agreed at Melbourne face-to-face, 10 December 2003

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"


Links: Dieter Roller, 15 Sep 2003     Announcement, 12 Sep 2003     Proposed resolution (Dieter Roller, 24 Nov 2003)     Satish Thatte, 24 Nov 2003     Dieter Roller, 24 Nov 2003     Proposed resolution (Dieter Roller, 29 Nov 2003)
Changes: 12 Sep 2003 - new issue;    15 Sep 2003 - fields: Links;    12 Nov 2003 - fields: Related issue;    24 Nov 2003 - fields: Links, Status, Proposed resolution;    29 Nov 2003 - fields: Links, Status, Proposed resolution;    10 Dec 2003 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 63: Support of Array

Status: open
Date added: 15 Sep 2003
Categories: Data handling, Asynchronous operations
Date submitted: 15 September 2003
Submitter: Ricky Ho
Description: Can BPEL declare a variable as a "collection" for a particular message type ? For example, if there is a <while> which will receive multiple incoming messages into an array variable. How does the BPEL look like ?

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>


Links: Ricky Ho, 13 Sep 2003     Ricky Ho, 13 Sep 2003     Mark Little, 15 Sep 2003     Ron Ten-Hove, 15 Sep 2003     Announcement, 15 Sep 2003     Ricky Ho, 15 Sep 2003     David RR Webber, 15 Sep 2003     Ricky Ho, 15 Sep 2003     David RR Webber, 15 Sep 2003     Francisco Curbera, 16 Sep 2003     Ricky Ho, 16 Sep 2003     Edwin Khodabakchian, 16 Sep 2003     Ricky Ho, 16 Sep 2003     David RR Webber, 16 Sep 2003     Ugo Corda, 16 Sep 2003     David RR Webber, 16 Sep 2003     Maciej Szefler, 17 Sep 2003     David RR Webber, 17 Sep 2003     Ricky Ho, 17 Sep 2003     Mark Little, 17 Sep 2003     David RR Webber, 17 Sep 2003     Ricky Ho, 17 Sep 2003     David RR Webber, 17 Sep 2003     Eckenfels. Bernd, 23 Sep 2003     David RR Webber, 23 Sep 2003     Eckenfels. Bernd, 23 Sep 2003     David RR Webber, 23 Sep 2003     Yaron Y. Goland, 25 Mar 2004     Kristofer Agren, 29 Mar 2004     Yaron Y. Goland, 9 Apr 2004     Kristofer Agren, 9 Apr 2004     Yaron Y. Goland, 12 Apr 2004     Kristofer Agren, 12 Apr 2004     Alex Yiu, 12 Apr 2004     Dieter Koenig1, 13 Apr 2004     Yaron Y. Goland, 13 Apr 2004     Yaron Y. Goland, 13 Apr 2004     Ivana Trickovic, 14 Apr 2004     Dieter Roller, 14 Apr 2004     Yaron Y. Goland, 14 Apr 2004     Dieter Roller, 14 Apr 2004     Discussed at Walldorf f-t-f (document details)
Changes: 15 Sep 2003 - new issue;    15 Sep 2003 - fields: Links;    16 Sep 2003 - fields: Links;    17 Sep 2003 - fields: Links;    23 Sep 2003 - fields: Links;    24 Sep 2003 - fields: Links;    25 Mar 2004 - fields: Links;    29 Mar 2004 - fields: Links;    10 Apr 2004 - fields: Links;    13 Apr 2004 - fields: Links;    14 Apr 2004 - fields: Links;    15 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links

Issue 64: Explicit declaration of process instantiation

Status: resolved
In spec: No change
Date added: 15 Sep 2003
Categories: Process lifecycle, State management
Date submitted: 15 September 2003
Submitter: Ricky Ho
Description: There is no way to pass data to "initialize the variables" of a newly creating process instance. The only thing that you can do is to put a <receive ... createInstance="yes"/> as the first activity so that the process instance can receive external data for variable initialization. This model seems attempt to treat every process instance "homogeneous" (they are same when they start). The fact that each process instance may have different values in their process variables is just because they receive different incoming call in their subsequent receive activity.

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
Therefore, rather than using the following ....
<process>
   ....
   <sequence>
   ....
     <receive partner="buyer" portType="p1" operation="submitOrder" 
variable="var1" createInstance="yes"/>
   ....
     <receive ..../>
   <sequence>
</process>
I suggest to use this ...
<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>.

Resolution: Proposed in Yaron Y. Goland, 5 Oct 2004, decided on 13 Oct 2004 conf call

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

Status: resolved
In spec: No change
Date added: 15 Sep 2003
Categories: Partner links, Correlation
Date submitted: 15 September 2003
Submitter: Ricky Ho
Description: Can there be multiple "partners" of a single "partner type" ? For example, in an auction scenario, can I model a seller process that deals with multiple "bidders" (the number of them is unknown) ? If so, how should I declare them in the "partner" section ? Am I actually declaring the "partner type" or the "individual partner" ?

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

Status: resolved
In spec: No change
Date added: 19 Sep 2003
Categories: Correlation
Date submitted: 16 September 2003
Submitter: Ricky Ho
Description:

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"/>
An instance of processC is executing
    <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

Status: resolved
In spec: 4 June 2004
Date added: 24 Sep 2003
Categories: concurrency control
Date submitted: 23 September 2003
Submitter: Satish Thatte
Champion: Satish Thatte
Document: Language specification, section 13.6
Description: There has been some recent discussion regarding the concurrency control semantics of serializable scopes. Yaron Goland had also raised a question regarding the possibility of deadlock among serializable scopes. This section needs additional wording to clarify these issues.
Resolution: Proposed in Satish Thatte, 16 Jan 2004, decided at conf call, 21 January 2004

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.

Links: Ron Ten-Hove, 15 Sep 2003     Announcement, 24 Sep 2003     Yaron Goland, 24 Sep 2003     Satish Thatte, 26 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Proposed resolution (Satish Thatte, 15 Jan 2004)     Ron Ten-Hove, 15 Jan 2004     Satish Thatte, 15 Jan 2004     Nickolas Kavantzas, 15 Jan 2004     Ron Ten-Hove, 16 Jan 2004     Proposed resolution (Satish Thatte, 16 Jan 2004)     Goran Olsson, 17 Jan 2004     Satish Thatte, 17 Jan 2004     Ron Ten-Hove, 17 Jan 2004
Changes: 24 Sep 2003 - new issue;    24 Sep 2003 - fields: Links;    25 Sep 2003 - fields: Links;    26 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links, Status, Proposed resolution;    16 Jan 2004 - fields: Links;    18 Jan 2004 - fields: Links, Status, Proposed resolution;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 68: catch syntax broken

Status: resolved
In spec: 4 June 2004
Date added: 26 Sep 2003
Categories: scopes, fault handling, syntax
Date submitted: 26 September 2003
Submitter: Satish Thatte
Document: Language specification
Description: The current catch syntax is 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 .."
Thus when the faultName is missing, the type of the faultVariable is unknown.
Resolution: Proposed in Satish Thatte, 15 Jan 2004, decided at conf call, 21 January 2004

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.

Links: Announcement, 26 Sep 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Proposed resolution (Satish Thatte, 15 Jan 2004)     Jim Clune, 15 Jan 2004     Satish Thatte, 15 Jan 2004     jim@parasoft.com, 15 Jan 2004     Satish Thatte, 15 Jan 2004     Proposed resolution (Satish Thatte, 15 Jan 2004)     Yaron Goland, 23 Jan 2004     Satish Thatte, 24 Jan 2004     Yaron Goland, 26 Jan 2004
Changes: 26 Sep 2003 - new issue;    26 Sep 2003 - fields: Links;    15 Jan 2004 - fields: Links, Status, Proposed resolution;    16 Jan 2004 - fields: Links, Status, Proposed resolution;    27 Jan 2004 - fields: Status, Proposed resolution, Resolution;    11 Feb 2004 - fields: Links;    9 Jun 2004 - fields: In spec

Issue 69: When to clear link status

Status: resolved
In spec: 4 June 2004
Date added: 27 Sep 2003
Categories: State management
Date submitted: 27 September 2003
Submitter: Yuzo Fujishima
Document: BPEL 1.1 Specification
Description:

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>


Resolution: Proposed in Maciej Szefler, 13 Feb 2004, decided at 18 Feb 2004 con call

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.
Section 12.5.1: Link Semantics

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

Status: resolved
In spec: 4 June 2004
Date added: 30 Sep 2003
Categories: State management
Date submitted: 26 September 2003
Submitter: Jim Clune
Description: The XML schema in the appendix of the BPEL 1.1 spec declares a default value of "no" for the suppressJoinFailure attribute in tActivity and tProcess complexType declarations. This makes sense for tProcess, as it establishes a default to be used until overridden. For tActivity, however, I think that specifying a default value contradicts this statement in section 12.5.2:

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"/>
with this:
<attribute name="suppressJoinFailure" type="bpws:tBoolean" use="optional"/>

Resolution: Proposed in Kevin Liu, 4 Feb 2004, decided at 18 Feb 2004 con call

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

Status: resolved
In spec: No change
Date added: 1 Oct 2003
Categories: Related standards
Date submitted: 01 October 2003
Submitter: Liu, Kevin
Document: Specification
Description: WSDL 1.2 has removed the message construct. We need to clarify how this WSDL change will impact BPEL.
Resolution: Proposed in Yaron Y. Goland, 5 Oct 2004, decided on 13 Oct 2004 conf call

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?

Status: resolved
In spec: 4 June 2004
Date added: 1 Oct 2003
Date submitted: 01 October 2003
Submitter: Liu, Kevin
Champion: Peter Furniss
Document: Specification
Description: WS-I BP1.0 provides clarifications and constraints on the use of WSDL1.1. We need to investigate and decide if BPEL should be aligned with BP1.0. In particular, a few questions need to be answered:

  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?

Resolution: Proposed in Peter Furniss, 12 Nov 2003, agreed at 26 November 2003 conf call meeting

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.

Links: Satish Thatte, 1 Oct 2003     Prasad Yendluri, 1 Oct 2003     Satish Thatte, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Eckenfels. Bernd, 1 Oct 2003     Satish Thatte, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Satish Thatte, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Satish Thatte, 1 Oct 2003     Kevin Liu, 1 Oct 2003     Kevin Liu, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Satish Thatte, 1 Oct 2003     Harvey Reed, 1 Oct 2003     Sid Askary, 1 Oct 2003     Eckenfels. Bernd, 1 Oct 2003     Eckenfels. Bernd, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Ugo Corda, 1 Oct 2003     Prasad Yendluri, 1 Oct 2003     Prasad Yendluri, 1 Oct 2003     Announcement, 1 Oct 2003     Ron Ten-Hove, 1 Oct 2003     Francisco Curbera, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Peter Furniss, 2 Oct 2003     Peter Furniss, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Peter Furniss, 2 Oct 2003     Peter Furniss, 2 Oct 2003     Ron Ten-Hove, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Kevin Liu, 2 Oct 2003     Kevin Liu, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Ugo Corda, 2 Oct 2003     Harvey Reed, 2 Oct 2003     Francisco Curbera, 3 Oct 2003     Tony Fletcher, 3 Oct 2003     Ugo Corda, 3 Oct 2003     Ugo Corda, 3 Oct 2003     Harvey Reed, 3 Oct 2003     Tony Fletcher, 3 Oct 2003     Ugo Corda, 3 Oct 2003         Eckenfels. Bernd, 6 Oct 2003         Satish Thatte, 6 Oct 2003     Ugo Corda, 6 Oct 2003     Danny van der Rijn, 6 Oct 2003     Eckenfels. Bernd, 7 Oct 2003     Dieter Roller, 7 Oct 2003     Peter Furniss, 9 Oct 2003     Ugo Corda, 9 Oct 2003     Peter Furniss, 9 Oct 2003     Ugo Corda, 9 Oct 2003     Danny van der Rijn, 9 Oct 2003     Peter Furniss, 9 Oct 2003     Danny van der Rijn, 9 Oct 2003     Kevin Liu, 15 Oct 2003     Yaron Goland, 20 Oct 2003     Ugo Corda, 20 Oct 2003     Proposed resolution (Peter Furniss, 22 Oct 2003)     Satish Thatte, 23 Oct 2003     Ugo Corda, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Yaron Goland, 24 Oct 2003     Ugo Corda, 24 Oct 2003     Peter Furniss, 24 Oct 2003     Ugo Corda, 24 Oct 2003     Yaron Goland, 27 Oct 2003     Ugo Corda, 27 Oct 2003     Francisco Curbera, 28 Oct 2003     Peter Furniss, 3 Nov 2003     Ugo Corda, 3 Nov 2003     Peter Furniss, 3 Nov 2003     Ugo Corda, 3 Nov 2003     Proposed resolution (Peter Furniss, 8 Nov 2003)     Yaron Goland, 10 Nov 2003     Eckenfels. Bernd, 10 Nov 2003     Ugo Corda, 10 Nov 2003     Peter Furniss, 11 Nov 2003     Peter Furniss, 11 Nov 2003     Ugo Corda, 11 Nov 2003     Francisco Curbera, 11 Nov 2003     Ugo Corda, 11 Nov 2003     Danny van der Rijn, 11 Nov 2003     Ugo Corda, 11 Nov 2003     Danny van der Rijn, 11 Nov 2003     Ugo Corda, 11 Nov 2003     Danny van der Rijn, 11 Nov 2003     Eckenfels. Bernd, 11 Nov 2003     Eckenfels. Bernd, 11 Nov 2003     Discussed at 12 Nov meeting     Proposed resolution (Peter Furniss, 12 Nov 2003)     Yaron Goland, 24 Nov 2003
Changes: 1 Oct 2003 - new issue;    1 Oct 2003 - fields: Links;    2 Oct 2003 - fields: Links;    3 Oct 2003 - fields: Links;    6 Oct 2003 - fields: Links;    8 Oct 2003 - fields: Links, Champion;    9 Oct 2003 - fields: Links;    10 Oct 2003 - fields: Links;    16 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    22 Oct 2003 - fields: Links, Status, Proposed resolution;    23 Oct 2003 - fields: Links;    24 Oct 2003 - fields: Links;    27 Oct 2003 - fields: Links;    29 Oct 2003 - fields: Links;    3 Nov 2003 - fields: Status, Proposed resolution, Links;    8 Nov 2003 - fields: Links, Status, Proposed resolution;    11 Nov 2003 - fields: Links;    12 Nov 2003 - fields: Links, Status, Proposed resolution;    25 Nov 2003 - fields: Links;    26 Nov 2003 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

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

Status: resolved
In spec: 4 June 2004
Date added: 6 Oct 2003
Date submitted: 05 October 2003
Submitter: Ugo Corda
Document: main BPEL TC document
Description: The example in section 10.2 incorrectly specifies a wsdl:fault element with a one-way operation, which is not allowed by WSDL 1.1.
<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> 

Submitter's proposal: Replace the example with:
<portType name="BuyerPT"> 
    <operation name="AsyncPurchaseResponse"> 
        <input message="smsg:POResponse"/> 
    </operation> 
    <operation name="AsyncPurchaseReject"> 
        <input message="smsg:POReject"/> 
    </operation> 
</portType> 

Resolution: Proposed in Ugo Corda, 8 Jan 2004, decided at conf call, 21 January 2004

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

Status: resolved
In spec: 4 June 2004
Date added: 9 Oct 2003
Date submitted: 09 October 2003
Submitter: Dieter Roller
Champion: Bernd Eckenfels
Description: The specs could possibly be interpreted in such a way that activities without an incoming link could also have a join condition. This is not the intended meaning.
Submitter's proposal: Modify the first sentence in the second paragraph in section 12.5.1 as follows :
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.
Furthermore it may be helpful to have a similar sentence earlier in the document.
Resolution: proposed in Eckenfels. Bernd, 25 Nov 2003, agreed at Melbourne face-to-face, 10 December 2003

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

B) change standard elements for each activity

- change formal syntax definition:

FROM
  <source .../>*
  <target .../>*
TO
  <sources>
    <source linkName="ncname" transitionCondition="bool-expr"?/>+
  </sources>?
  <targets joinCondition="bool-expr"? >
    <target linkName="ncname"/>+
  </targets>?

- add description of "joinCondition" attribute right below (above 11.3) (removed default value, replaced with default semantic):

The value of the joinCondition attribute is a Boolean-valued expression in the expression language indicated for this document (see Expressions). If this attribute is not present, the join condition is the logical OR of the link status of all incoming links of this activity (see 12.5.1 Link semantics).
(this also aligns the semantic definition with 12.5.1 without using the "default value")

- change text of 11.2: FROM

Each BPEL4WS activity has optional nested standard elements <source> and <target>. The use...
TO
Each BPEL4WS activity has nested standard elements <source> and <target> within the optional containers <sources> and <targets>. The use...
C) update all samples and schema
Links: Announcement, 9 Oct 2003     Eckenfels. Bernd, 14 Oct 2003     Yaron Goland, 20 Oct 2003     Ron Ten-Hove, 20 Oct 2003     Frank Leymann, 21 Oct 2003     Yaron Goland, 22 Oct 2003     Frank Leymann, 23 Oct 2003     Ron Ten-Hove, 23 Oct 2003     Eckenfels. Bernd, 29 Oct 2003     Yaron Goland, 31 Oct 2003     Eckenfels. Bernd, 11 Nov 2003     Eckenfels. Bernd, 25 Nov 2003     Yaron Goland, 1 Dec 2003     Eckenfels. Bernd, 2 Dec 2003     Yaron Goland, 3 Dec 2003     Eckenfels. Bernd, 4 Dec 2003
Changes: 9 Oct 2003 - new issue;    10 Oct 2003 - fields: Links;    14 Oct 2003 - fields: Links;    20 Oct 2003 - fields: Links;    21 Oct 2003 - fields: Links;    22 Oct 2003 - fields: Links;    23 Oct 2003 - fields: Links;    29 Oct 2003 - fields: Links;    31 Oct 2003 - fields: Links;    11 Nov 2003 - fields: Champion;    12 Nov 2003 - fields: Links;    26 Nov 2003 - fields: Links;    2 Dec 2003 - fields: Links;    3 Dec 2003 - fields: Links;    5 Dec 2003 - fields: Links;    9 Dec 2003 - fields: Status, Proposed resolution;    10 Dec 2003 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 75: Locally Scoped partnerLink declarations

Status: resolved
In spec: 1.35, 30 June 2004
Date added: 21 Oct 2003
Categories: Partner links, Compensation, State management
Date submitted: 21 October 2003
Submitter: Yaron Goland
Document: Main Spec
Description: The inability to define partnerLinks inside of local scopes causes problems, especially with compensation handlers. The group either needs to provide for the ability to define partnerLinks in local scopes or it needs to put in an explanation in the spec for why it isn't possible to have locally scoped partnerLink definitions and then provide some alternate mechanism for dealing with the problems compensation handlers face in dealing with partnerLinks.
Resolution: Proposed in Yaron Y. Goland, 19 May 2004, decided at conf call 9 June 2004

It is proposed that the BPEL specification be modified to allow for the declaration of partnerLinks within scopes. Such a declaration would be accomplished by allowing for the use of the partnerLinks element as a child of the scope element. partnerLinks will be treated similarly to BPEL variable in terms of life cycle management, name collision resolution, etc.
Links: Announcement, 21 Oct 2003     Yaron Goland, 21 Oct 2003     Harvey Reed, 21 Oct 2003     Yaron Goland, 22 Oct 2003     Edwin Khodabakchian, 22 Oct 2003     Assaf Arkin, 23 Oct 2003     Frank Leymann, 23 Oct 2003     Assaf Arkin, 13 Nov 2003     Satish Thatte, 14 Nov 2003     Frank Leymann, 14 Nov 2003     Assaf Arkin, 14 Nov 2003     Assaf Arkin, 14 Nov 2003     Satish Thatte, 16 Nov 2003     Assaf Arkin, 17 Nov 2003     Satish Thatte, 17 Nov 2003     Yaron Goland, 27 Nov 2003     Assaf Arkin, 30 Nov 2003     Assaf Arkin, 2 Dec 2003     Discussed at Walldorf f-t-f (document details)     Yaron Y. Goland, 28 Apr 2004     Proposed resolution (Yaron Y. Goland, 19 May 2004)     Yaron Y. Goland, 20 May 2004
Changes: 21 Oct 2003 - new issue;    21 Oct 2003 - fields: Links;    22 Oct 2003 - fields: Links;    23 Oct 2003 - fields: Links;    13 Nov 2003 - fields: Links;    14 Nov 2003 - fields: Links;    16 Nov 2003 - fields: Links;    17 Nov 2003 - fields: Links;    27 Nov 2003 - fields: Links;    30 Nov 2003 - fields: Links;    2 Dec 2003 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    19 May 2004 - fields: Links, Status, Proposed resolution;    20 May 2004 - fields: Links;    9 Jun 2004 - fields: Status, Proposed resolution, Resolution;    15 Jul 2004 - fields: In spec


Issue 76: Mandating either Pessimistic or Optimistic Static Analysis

Status: resolved
In spec: no change
Date added: 21 Oct 2003
Categories: Syntax and validation
Date submitted: 21 October 2003
Submitter: Yaron Goland
Document: Main Spec
Description: The spec does not mandate that BPEL engines be either pessimistic or optimistic in their static analysis. Therefore programmers can never know ahead of time what kind of engine they will end up on which all but guarantees portability problems. The spec therefore needs to mandate either pessimistic or optimistic static analysis behavior.
Resolution: Proposed in Yaron Goland, 8 Nov 2003, accepted at 12 November meeting

This issue is a duplicate of issue 9 : Static analysis

Links: Announcement, 21 Oct 2003     Yaron Goland, 21 Oct 2003     Eckenfels. Bernd, 21 Oct 2003     Harvey Reed, 22 Oct 2003     Proposed resolution (Yaron Goland, 8 Nov 2003)
Changes: 21 Oct 2003 - new issue;    21 Oct 2003 - fields: Links;    22 Oct 2003 - fields: Links;    8 Nov 2003 - fields: Links, Status, Proposed resolution;    12 Nov 2003 - fields: Status, Proposed resolution, Resolution


Issue 77: BPEL cannot handle some SOAP header bindings

Status: resolved
In spec: no change
Date added: 21 Oct 2003
Date submitted: 21 October 2003
Submitter: Ugo Corda
Description: Let's suppose we have the following WSDL file:
<message name="In"> 
    <part name="InPart" element="InElement"/> 
</message> 

<message name="Header"> <part name="HeaderPart" element="HeaderElement"/> </message>

<portType name="myPortType"> <operation name="op1"> <input message="In"/> </operation> </portType>

<binding type="myPortType" ... > <soap:binding ..../> <operation name="op1"> <input> <soap:body parts="InPart" ...> <soap:header message="Header" part="HeaderPart" .../> </input> </operation> </binding>

In this example, the abstract operation "op1" refers to message "In", but the binding brings in an additional second message, "Header", for the concrete operation.

It seems that BPEL would not be able to process the "Header" information in any way. For instance, a "receive" operation would only be able to specify one inputVariable, which would be associated with the "In" message and not the "Header" message. In other words, the "Header" message would carry information to the "receive" operation that BPEL would have no access to.

If this is the case, new Web services defined with BPEL in mind could easily modify this scenario by defining both body and header as being part of a single message, but legacy Web services might be out of reach for BPEL.
Resolution: agreed to close with no change in Web ballot (ended 08 Dec 2003)
Vote announcement: Web ballot (ends 08 Dec 2003)
Links: Ugo Corda, 20 Oct 2003     Frank Leymann, 21 Oct 2003     Ugo Corda, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Peter Furniss, 21 Oct 2003     Ugo Corda, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Ugo Corda, 21 Oct 2003     Satish Thatte, 21 Oct 2003     Ugo Corda, 21 Oct 2003     Announcement (erroneously stating as issue 78)     Rajesh Pradhan, 21 Oct 2003     Francisco Curbera, 21 Oct 2003     Ugo Corda, 21 Oct 2003     Reannouncement as issue 77     Peter Furniss, 22 Oct 2003     Peter Furniss, 22 Oct 2003     Ugo Corda, 22 Oct 2003     Yaron Goland, 22 Oct 2003     Satish Thatte, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Frank Leymann, 23 Oct 2003     Peter Furniss, 23 Oct 2003     Ugo Corda, 23 Oct 2003     Ugo Corda, 23 Oct 2003     Frank Leymann, 24 Oct 2003     Maciej Szefler, 27 Oct 2003     jim@parasoft.com, 27 Oct 2003     Yaron Goland, 27 Oct 2003     Frank Leymann, 31 Oct 2003     Ugo Corda, 31 Oct 2003     Ron Ten-Hove, 31 Oct 2003     Ugo Corda, 31 Oct 2003     Ron Ten-Hove, 1 Nov 2003     Ugo Corda, 1 Nov 2003     Satish Thatte, 2 Nov 2003     Ugo Corda, 2 Nov 2003     Ugo Corda, 2 Nov 2003     Satish Thatte, 2 Nov 2003     Ugo Corda, 2 Nov 2003     Satish Thatte, 3 Nov 2003     Satish Thatte, 3 Nov 2003     Frank Leymann, 3 Nov 2003     Ugo Corda, 3 Nov 2003     Satish Thatte, 4 Nov 2003     Ugo Corda, 4 Nov 2003     Satish Thatte, 4 Nov 2003     Ugo Corda, 4 Nov 2003     Satish Thatte, 4 Nov 2003     Ugo Corda, 4 Nov 2003     Satish Thatte, 4 Nov 2003     Harvey Reed, 4 Nov 2003     Satish Thatte, 4 Nov 2003     Ugo Corda, 4 Nov 2003     John Yunker, 4 Nov 2003     Yaron Goland, 19 Nov 2003     Yaron Goland, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ron Ten-Hove, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Rajesh Pradhan, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Harvey Reed, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Ron Ten-Hove, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Satish Thatte, 19 Nov 2003     Ugo Corda, 19 Nov 2003     Francisco Curbera, 19 Nov 2003     Ugo Corda, 20 Nov 2003     Sanjiva Weerawarana, 20 Nov 2003     Ugo Corda, 20 Nov 2003     Sanjiva Weerawarana, 20 Nov 2003     Ugo Corda, 20 Nov 2003     Ron Ten-Hove, 20 Nov 2003     Ugo Corda, 20 Nov 2003     Ron Ten-Hove, 21 Nov 2003     Ron Ten-Hove, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Sanjiva Weerawarana, 21 Nov 2003     Sanjiva Weerawarana, 21 Nov 2003     Sanjiva Weerawarana, 21 Nov 2003     Francisco Curbera, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Satish Thatte, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Sanjiva Weerawarana, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Satish Thatte, 21 Nov 2003     Ugo Corda, 21 Nov 2003     Sanjiva Weerawarana, 24 Nov 2003     Ugo Corda, 24 Nov 2003     Proposed resolution (Ugo Corda, 24 Nov 2003)     Sanjiva Weerawarana, 24 Nov 2003     Ugo Corda, 24 Nov 2003     Ron Ten-Hove, 25 Nov 2003     Sanjiva Weerawarana, 25 Nov 2003     Edwin Khodabakchian, 25 Nov 2003     Ugo Corda, 25 Nov 2003     Ugo Corda, 25 Nov 2003     Ron Ten-Hove, 25 Nov 2003     Ugo Corda, 25 Nov 2003     Ron Ten-Hove, 26 Nov 2003     Ugo Corda, 26 Nov 2003     Sanjiva Weerawarana, 27 Nov 2003     Ugo Corda, 27 Nov 2003     Sanjiva Weerawarana, 30 Nov 2003     Ugo Corda, 1 Dec 2003     Ron Ten-Hove, 1 Dec 2003     Ugo Corda, 1 Dec 2003     Ron Ten-Hove, 1 Dec 2003     Ugo Corda, 1 Dec 2003     Ron Ten-Hove, 1 Dec 2003     Ugo Corda, 2 Dec 2003     Yaron Goland, 2 Dec 2003     Ron Ten-Hove, 3 Dec 2003     Peter Furniss, 3 Dec 2003
Changes: 21 Oct 2003 - new issue;    22 Oct 2003 - fields: Links;    23 Oct 2003 - fields: Links;    24 Oct 2003 - fields: Links;    27 Oct 2003 - fields: Links;    31 Oct 2003 - fields: Links;    1 Nov 2003 - fields: Links;    2 Nov 2003 - fields: Links;    3 Nov 2003 - fields: Links;    4 Nov 2003 - fields: Links;    19 Nov 2003 - fields: Links;    20 Nov 2003 - fields: Links;    21 Nov 2003 - fields: Links;    24 Nov 2003 - fields: Links, Status, Proposed resolution;    25 Nov 2003 - fields: Links;    26 Nov 2003 - fields: Links;    27 Nov 2003 - fields: Status, Vote announcement, Links;    30 Nov 2003 - fields: Links;    1 Dec 2003 - fields: Links;    2 Dec 2003 - fields: Links;    3 Dec 2003 - fields: Links;    10 Dec 2003 - fields: Status, Proposed resolution, Resolution


Issue 78: New value for initiate on multi-starts

Status: resolved
In spec: No change
Date added: 22 Oct 2003
Categories: Correlation
Date submitted: 22 October 2003
Submitter: Yaron Goland
Description: The use of the initiate attribute on correlations in multi-start activities can easily lead to misunderstanding. The 'initiate='yes'' value is only true on the first multi-start activity that fires, the rest are magically transformed into 'initiate='no'' once the first multi-start fires. One can easily imagine the resulting confusion. To prevent this confusion perhaps we should add a new value for initiate such as 'initiate='multistart''. This shows that the programmer understands the special semantics of correlation sets on multi-start activities.
Resolution: Proposed verbally by Yaron Goland and decided at San Francisco f-t-f

Closed as a subset of issue 37 : Initiating Correlation Set More Than Once
Links: Announcement, 22 Oct 2003     Edit group action (Satish Thatte, 14 Jan 2004)     Yaron Y. Goland, 26 Mar 2004
Changes: 22 Oct 2003 - new issue;    22 Oct 2003 - fields: Links;    15 Jan 2004 - fields: Links;    26 Mar 2004 - fields: Links;    22 Jun 2004 - fields: In spec, Resolution, Status


Issue 79: Serializable scopes do not need to be leaf scopes

Status: resolved
In spec: 4 June 2004
Date added: 22 Oct 2003
Date submitted: 22 October 2003
Submitter: Ron Ten-Hove
Document: BPEL 1.1 Specification
Description: The specification states that "Serializable scopes must not be nested. A scope marked with variableAccessSerializable="yes" must be a leaf scope."

The latter requirement is too restrictive. Sub-scopes can be included in a serializable scope, and will be treated as logically part of the serializable scope. What should be banned are nested serializable scopes.
Proposed resolution: Ron Ten-Hove, 11 Nov 2003
Resolution: Proposed in Ron Ten-Hove, 11 Nov 2003, accepted at 12 November meeting

Section 13.6, first paragraph, in the input text reads:

When the variableAccessSerializable attribute is set to "yes", the scope provides concurrency control in governing access to shared variables. Such a scope is called a serializable scope. Serializable scopes must not be nested. A scope marked with variableAccessSerializable="yes" must be a leaf scope.

The final sentence should be modified such that the paragraph should read a follows:

When the variableAccessSerializable attribute is set to "yes", the scope provides concurrency control in governing access to shared variables. Such a scope is called a serializable scope. Serializable scopes must not be nested. A scope marked with variableAccessSerializable="yes" must not contain other serializable scopes, but may contain scopes that are not marked as serializable. In the latter case, access to shared variables from within such enclosed scopes is controlled by the enclosing serializable scope.

Note that this should be borne in mind in considering and applying issue 36 : Multiple instances of event handler and issue 62 : Event handlers and Serializable Scopes
Links: Satish Thatte, 22 Oct 2003     Dieter Roller, 22 Oct 2003     Announcement, 22 Oct 2003     Proposed resolution (Ron Ten-Hove, 11 Nov 2003)     Eckenfels. Bernd, 11 Nov 2003
Changes: 22 Oct 2003 - new issue;    22 Oct 2003 - fields: Links;    11 Nov 2003 - fields: Status, Proposed resolution, Links;    12 Nov 2003 - fields: Links, Status, Resolution;    9 Jun 2004 - fields: In spec


Issue 80: Clarify Fault Handler Selection When Fault Data is Absent

Status: resolved
In spec: 4 June 2004
Date added: 31 Oct 2003
Categories: Fault handling
Date submitted: 29 October 2003
Submitter: Satish Thatte
Document: BPEL 1.1 Specification
Description: Section 13.4 of the BPEL 1.1 spec has the following line:
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value will be selected if present.

This is misleading because it suggests that such a catch activity will be selected even if it specifies a faultVariable.

For instance:

<scope>
  <faulthandlers>
     <catch faultName="x:foo" faultVariable="bar">
           <empty/>
     </catch>
     <catchAll>
           <empty/>
     </catchAll>
  </faulthandlers>
  <throw faultName="x:foo"/>
</scope>

The wording suggests that the first fault handler will be invoked rather than the catchAll.


Submitter's proposal:

Change the sentence to:

1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value, and no faultVariable attribute, will be selected if present. Otherwise, the default catchAll handler is selected if present.

Resolution: Proposed in Peter Furniss, 20 Feb 2004, decided at conference call 3 March 2004

Change the line in Section 13.4 of the BPEL 1.1 spec

1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value will be selected if present.
To:
1. If the fault has no associated fault data, a catch activity that specifies a matching faultName value, and no faultVariable attribute, will be selected if present. Otherwise, the default catchAll handler is selected if present.

Links: Announcement, 2 Nov 2003     Proposed resolution (Peter Furniss, 20 Feb 2004)
Changes: 31 Oct 2003 - new issue;    2 Nov 2003 - fields: Links;    23 Feb 2004 - fields: Links, Status, Proposed resolution;    3 Mar 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 81: Are start activities that aren't createInstance activities legal?

Status: resolution proposed
Date added: 3 Nov 2003
Categories: Process lifecycle, State management
Date submitted: 31 October 2003
Submitter: Yaron Goland
Document: Main doc
Description: It is currently unclear if the spec requires that all initial activities be start activities (i.e. have createInstance="true") or not.

In other words is the following legal?

<process>
   ...
   <flow>
      <receive createInstance="yes".../>
      <receive createInstance="no".../>
   </flow>
</process>

Proposed resolution: Yaron Y. Goland, 1 Dec 2004
Links: Satish Thatte, 22 Oct 2003     Yaron Goland, 22 Oct 2003     Ron Ten-Hove, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Danny van der Rijn, 23 Oct 2003     Frank Leymann, 24 Oct 2003     Yaron Goland, 27 Oct 2003     Yaron Goland, 27 Oct 2003     Frank Leymann, 31 Oct 2003     Eckenfels. Bernd, 31 Oct 2003     Danny van der Rijn, 31 Oct 2003     Announcement, 3 Nov 2003     Yaron Y. Goland, 27 Aug 2004     Ugo Corda, 27 Aug 2004     Yaron Y. Goland, 28 Aug 2004     Ugo Corda, 28 Aug 2004     Satish Thatte, 31 Aug 2004     Ugo Corda, 31 Aug 2004     Satish Thatte, 31 Aug 2004     Ugo Corda, 31 Aug 2004     Satish Thatte, 31 Aug 2004     Ugo Corda, 31 Aug 2004     Yaron Y. Goland, 10 Sep 2004     Satish Thatte, 10 Sep 2004     Ugo Corda, 10 Sep 2004     Ron Ten-Hove, 10 Sep 2004     Ugo Corda, 10 Sep 2004     Satish Thatte, 10 Sep 2004     Ugo Corda, 10 Sep 2004     Satish Thatte, 10 Sep 2004     Ugo Corda, 10 Sep 2004     Satish Thatte, 10 Sep 2004     Ugo Corda, 10 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Satish Thatte, 14 Sep 2004     Ugo Corda, 14 Sep 2004     Yaron Y. Goland, 14 Sep 2004     Francisco Curbera, 14 Sep 2004     Satish Thatte, 14 Sep 2004     Ugo Corda, 14 Sep 2004     Francisco Curbera, 14 Sep 2004     Ugo Corda, 14 Sep 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)     Francisco Curbera, 16 Sep 2004     Yaron Y. Goland, 16 Sep 2004     Francisco Curbera, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Proposed resolution (Yaron Y. Goland, 17 Sep 2004)     Alex Yiu, 20 Sep 2004     Maciej Szefler, 25 Sep 2004     Ugo Corda, 25 Sep 2004     Maciej Szefler, 25 Sep 2004     Ugo Corda, 25 Sep 2004     Maciej Szefler, 25 Sep 2004     Ugo Corda, 26 Sep 2004     Maciej Szefler, 26 Sep 2004     Proposed resolution (Yaron Y. Goland, 27 Sep 2004)     Yaron Y. Goland, 27 Sep 2004     Satish Thatte, 27 Sep 2004     Satish Thatte, 29 Sep 2004     Yaron Y. Goland, 29 Sep 2004     Proposed resolution (Yaron Y. Goland, 1 Dec 2004)     Yuzo Fujishima, 3 Dec 2004     Yaron Y. Goland, 4 Dec 2004     Yuzo Fujishima, 6 Dec 2004     Satish Thatte, 6 Dec 2004     Yaron Y. Goland, 6 Dec 2004
Changes: 3 Nov 2003 - new issue;    3 Nov 2003 - fields: Links;    27 Aug 2004 - fields: Links;    30 Aug 2004 - fields: Links;    31 Aug 2004 - fields: Links;    10 Sep 2004 - fields: Links;    11 Sep 2004 - fields: Links;    14 Sep 2004 - fields: Links;    15 Sep 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;    27 Sep 2004 - fields: Links, Status, Proposed resolution;    28 Sep 2004 - fields: Links;    30 Sep 2004 - fields: Links;    2 Dec 2004 - fields: Links, Status, Proposed resolution;    3 Dec 2004 - fields: Links;    5 Dec 2004 - fields: Links;    7 Dec 2004 - fields: Links

Issue 82: description of abstract processes in spec

Status: resolution proposed
Date added: 3 Nov 2003
Categories: Abstract processes
Date submitted: 01 November 2003
Submitter: Ben Bloch
Document: BPEL 1.1 Specification
Description: Better describe abstract processes in spec, particularly in terms of what they are, what they are not, and the relationshop between abstract and executable processes. This is mostly wordsmithing the spec along the lines of the messages Steve Capell, 23 Oct 2003, Ben Bloch, 24 Oct 2003, Frank Leymann, 25 Oct 2003 (identified in the list below as "possible text").
Proposed resolution: Peter Furniss, 14 Dec 2004 Assaf Arkin, 14 Dec 2004
Links: (Note considerable discussion before formal raising of an issue)     Peter Furniss, 22 Oct 2003     Satish Thatte, 23 Oct 2003     possible text (Steve Capell, 23 Oct 2003)     Satish Thatte, 23 Oct 2003     Steve Capell, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Harvey Reed, 23 Oct 2003     Tony Andrews, 23 Oct 2003     Harvey Reed, 23 Oct 2003     Tony Andrews, 23 Oct 2003     Ben Bloch, 23 Oct 2003     Tony Andrews, 23 Oct 2003     Jean-Jacques Dubray, 23 Oct 2003     Danny van der Rijn, 23 Oct 2003     Steve Capell, 23 Oct 2003     David RR Webber, 23 Oct 2003     Satish Thatte, 23 Oct 2003     Jean-Jacques Dubray, 23 Oct 2003     Steve Capell, 23 Oct 2003     Frank Leymann, 24 Oct 2003     possible text (Ben Bloch, 24 Oct 2003)     Derek Miers, 24 Oct 2003     Tony Andrews, 24 Oct 2003     possible text (Frank Leymann, 25 Oct 2003)     Announcement, 3 Nov 2003     Philip Rossomando, 26 Jan 2004     Ben Bloch, 27 Jan 2004     Discussed at Walldorf f-t-f (document details)     Proposed resolution (rkhalaf, 8 Oct 2004)     Peter Furniss, 11 Oct 2004     Martin Chapman, 11 Oct 2004     rkhalaf, 11 Oct 2004     rkhalaf, 11 Oct 2004     Peter Furniss, 11 Oct 2004     Yaron Y. Goland, 11 Oct 2004     Danny van der Rijn, 11 Oct 2004     Martin Chapman, 12 Oct 2004     Yaron Y. Goland, 13 Oct 2004     Satish Thatte, 13 Oct 2004     Peter Furniss, 13 Oct 2004     Peter Furniss, 13 Oct 2004     Martin Chapman, 13 Oct 2004     Ivana Trickovic, 13 Oct 2004     Martin Chapman, 13 Oct 2004     Ivana Trickovic, 13 Oct 2004     Ivana Trickovic, 13 Oct 2004     rkhalaf, 13 Oct 2004     rkhalaf, 13 Oct 2004     Danny van der Rijn, 13 Oct 2004     Danny van der Rijn, 13 Oct 2004     Monica J. Martin, 13 Oct 2004     rkhalaf, 13 Oct 2004     Monica J. Martin, 13 Oct 2004     rkhalaf, 13 Oct 2004     Martin Chapman, 13 Oct 2004     rkhalaf, 13 Oct 2004     Diane Jordan, 13 Oct 2004     rkhalaf, 14 Oct 2004     Danny van der Rijn, 14 Oct 2004     Yaron Y. Goland, 14 Oct 2004     Yaron Y. Goland, 14 Oct 2004     rkhalaf, 14 Oct 2004     rkhalaf, 15 Oct 2004     Proposed resolution (Peter Furniss, 1 Dec 2004)     Danny van der Rijn, 1 Dec 2004     Peter Furniss, 2 Dec 2004     Danny van der Rijn, 2 Dec 2004     rkhalaf, 2 Dec 2004     Martin Chapman, 2 Dec 2004     rkhalaf, 2 Dec 2004     Ivana Trickovic, 3 Dec 2004     Satish Thatte, 5 Dec 2004     Charlton Barreto, 11 Dec 2004     Satish Thatte, 13 Dec 2004     andrew.francis, 13 Dec 2004     Satish Thatte, 13 Dec 2004     Peter Furniss, 13 Dec 2004     Charlton Barreto, 13 Dec 2004     Proposed resolution (Peter Furniss, 14 Dec 2004)     Assaf Arkin, 14 Dec 2004     rkhalaf, 14 Dec 2004     Peter Furniss, 14 Dec 2004     Charlton Barreto, 15 Dec 2004     Charlton Barreto, 15 Dec 2004     Assaf Arkin, 15 Dec 2004     Charlton Barreto, 15 Dec 2004     Peter Furniss, 15 Dec 2004
Changes: 3 Nov 2003 - new issue;    3 Nov 2003 - fields: Links;    2 Feb 2004 - fields: Links;    22 Apr 2004 - fields: Links;    11 Oct 2004 - fields: Links, Status, Proposed resolution;    12 Oct 2004 - fields: Links;    13 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Links;    15 Oct 2004 - fields: Links;    18 Oct 2004 - fields: Links;    2 Dec 2004 - fields: Links, Status, Proposed resolution;    3 Dec 2004 - fields: Links;    5 Dec 2004 - fields: Links;    11 Dec 2004 - fields: Links;    14 Dec 2004 - fields: Links, Status, Proposed resolution;    15 Dec 2004 - fields: Links;    16 Dec 2004 - fields: Links

Issue 83: Garbage Collecting Compensation Handlers

Status: resolved
In spec: no change
Date added: 3 Nov 2003
Categories: Compensation, Process coordination
Date submitted: 31 October 2003
Submitter: Yaron Goland
Document: Main Doc
Description: BPEL processes can potentially be very long lived and after a certain point compensation handlers persisted earlier in the process's lifetime may no longer be needed. We need a way to let the BPEL engine know that it can garbage collect unneeded compensation handlers. We can do this implicitly through hacky tricks like defining empty compensation handlers or we can introduce a more explicit way to identify a scope whose compensation handlers can be safely garbage collected.
Revisitable: Yes
Resolution: Proposed in Yaron Y. Goland, 19 May 2004, decided at conf call 9 June 2004 Closed with no change.
Rationale: Although I strongly believe that this issue brings up an important BPEL scenario I recognize that it is not in the 80 of the 80/20 case and in the interests of shipping BPEL before I retire I think we can skip it for this release.

Yaron
Links: Yaron Goland, 30 Oct 2003     Assaf Arkin, 31 Oct 2003     Frank Leymann, 31 Oct 2003     Announcement, 3 Nov 2003     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Yaron Y. Goland, 19 May 2004)     Yaron Y. Goland, 20 May 2004
Changes: 3 Nov 2003 - new issue;    3 Nov 2003 - fields: Links;    22 Apr 2004 - fields: Links;    19 May 2004 - fields: Links, Status, Proposed resolution;    20 May 2004 - fields: Links


Issue 84: Require Static Analysis Description & List

Status: resolved
Date added: 5 Nov 2003
Categories: Syntax and validation
Date submitted: 22 October 2003
Submitter: Yaron Goland
Document: Main Spec
Description: BPEL's semantics depend on the use of static analysis before run time in order to prevent entire classes of errors, errors whose existence the spec assumes to be impossible at runtime and therefore makes no provisions to handle. Unfortunately the static analysis requirements as currently defined in the BPEL spec are implicit rather than explicit which makes portability very difficult as implementers have no way to be sure they have completely implemented all the static analysis steps the spec relies on.
Submitter's proposal: The BPEL spec be required to explicit define all static analysis checks that BPEL's semantics depend on in the text of the standard.

Add an appendix, much like the existing fault summary appendix, that will provide a single checklist of all static analysis requirements with a brief description of their function.
Resolution: Proposed in Yaron Y. Goland, 4 Jun 2004, decided at San Francisco f-t-f

It is moved that the BPEL spec be required to provide an explicit list in a single location of all static analysis checks mandated by the spec. It is recommended that the editors produce a list similar to the one provided in Appendix A for standard faults.
Links: Announcement, 5 Nov 2003     Proposed resolution (Yaron Y. Goland, 4 Jun 2004)
Changes: 5 Nov 2003 - new issue;    5 Nov 2003 - fields: Links;    9 Jun 2004 - fields: Links, Status, Proposed resolution;    23 Jun 2004 - fields: Status, Proposed resolution, Resolution


Issue 85: Multiple links with the same source and target

Status: resolved
In spec: 4 June 2004
Date added: 17 Nov 2003
Date submitted: 16 November 2003
Submitter: Dieter Koenig
Document: BPEL4WS 1.1 (May 5, 2003), Section 12.5, "Flow"
Description: In the BPEL4WS 1.1 specification of May 5, 2003, Section 12.5, "Flow", introduces the flow activity, contained link elements, and defines constraints for referring to links in activity standard elements source and target. The specification allows multiple links to have the same source and the same target. There is no need to allow this. The referred conditions may easily combined into one. Example:
   <flow ...>
     <links>
       <link name="AtoB-1"/>
       <link name="AtoB-2"/>
     </links>
     <invoke name="A" ...>
       <source linkName="AtoB-1" transitionCondition="P1"/>
       <source linkName="AtoB-2" transitionCondition="P2"/>
       ...
      </invoke>
     <invoke name="B" ...>
       <target linkName="AtoB-1"/>
       <target linkName="AtoB-2"/>
       ...
     </invoke>
   </flow>

Submitter's proposal: Add an explicit constraint to the specification text that disallows multiple links to have the same source and the same target.
Resolution: proposed in Dieter Koenig1, 20 Nov 2003, agreed at Melbourne face-to-face, 10 December 2003

In section 12.5, "Flow", add an explicit constraint to the specification text that disallows multiple links to have the same source and the same target.

Vote 11 for, 8 against, plus abstentions (meeting was quorate)
Links: Announcement, 17 Nov 2003     Proposed resolution (Dieter Koenig1, 20 Nov 2003)
Changes: 17 Nov 2003 - new issue;    17 Nov 2003 - fields: Links;    20 Nov 2003 - fields: Links, Status, Proposed resolution;    10 Dec 2003 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec


Issue 86: Addressing Interoperability / Portability - SOAP 1.2

Status: open
Date added: 25 Nov 2003
Categories: Related standards
Date submitted: 24 November 2003
Submitter: Monica J. Martin
Document: BPEL specification
Description: SOAP 1.2 is a direct replacement for SOAP 1.1, a current component of BP 1.0. Both are instances of a WSDL protocol binding. SOAP 1.2 is a full W3C Recommendation while SOAP 1.1 is only a Note. It is expected that WS-I BP 2.0 will include SOAP 1.2 and WSDL 1.2/2.0. Therefore, we should consider how we address SOAP 1.2 consistent with our current and future resolve for BP 1.0 and WSDL 1.2/2.0 while also anticipating the upcoming BP 1.1 (attachments).

In addition, recommend we discuss how this affects interoperability and portability, and whether implementation guidelines would be in order (coordination with implementation subgroup is recommended).
Qualifier: clarification
Links: Announcement, 25 Nov 2003     Ugo Corda, 25 Nov 2003     Monica J. Martin, 26 Nov 2003
Changes: 25 Nov 2003 - new issue;    26 Nov 2003 - fields: Links;    27 Nov 2003 - fields: Links


Issue 87: Optional SOAP Headers

Status: resolved
In spec: No change
Date added: 27 Nov 2003
Categories: Related standards
Date submitted: 26 November 2003
Submitter: Yaron Goland
Document: Main BPEL Doc
Description: A key feature of the SOAP messaging model is the concept of intermediaries and the ability of intermediaries to insert headers into SOAP messages as they are routed. A direct consequence of this model is that SOAP messages may contain optional headers, that is, headers that sometimes are included in the message and sometimes not. BPEL processes need access to these optional headers because these headers often contain application relevant information, especially in the case where application (as opposed to infrastructure) intermediaries are involved.

Unfortunately WSDL does not define how one should specify an optional message part in an abstract definition. To resolve this ambiguity and to fully support SOAP it is necessary for BPEL to introduce a mechanism that allows the BPEL process to specify that a particular message part in an abstract message definition is optional.
Revisitable: Yes
Resolution: Proposed in Yaron Y. Goland, 29 Nov 2004, decided conf call 8 Dec 2004

Given the outcome of the vote on issue 87.1 I propose that we close issue 87 with no change to the spec and mark it as revistable.
Links: Announcement, 27 Nov 2003     Ugo Corda, 27 Nov 2003     Yaron Y. Goland, 27 Aug 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)     Ugo Corda, 16 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Ugo Corda, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Yaron Y. Goland, 17 Sep 2004     Satish Thatte, 17 Sep 2004     Ugo Corda, 18 Sep 2004     Frank Leymann, 19 Sep 2004     Yaron Y. Goland, 27 Sep 2004     Yaron Y. Goland, 27 Sep 2004     Ugo Corda, 27 Sep 2004     Eckenfels. Bernd, 4 Oct 2004     Yaron Y. Goland, 5 Oct 2004     Satish Thatte, 6 Oct 2004     Kristofer Agren, 6 Oct 2004     Francisco Curbera, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Danny van der Rijn, 6 Oct 2004     Satish Thatte, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Eckenfels. Bernd, 6 Oct 2004     Satish Thatte, 7 Oct 2004     Proposed resolution (Yaron Y. Goland, 29 Nov 2004)
Changes: 27 Nov 2003 - new issue;    27 Nov 2003 - fields: Links;    28 Nov 2003 - fields: Links;    27 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    17 Sep 2004 - fields: Links;    18 Sep 2004 - fields: Links;    20 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    29 Sep 2004 - fields: Links, Status, Proposed resolution;    7 Oct 2004 - fields: Split by hand;    11 Oct 2004 - fields: Links;    30 Nov 2004 - fields: Links, Status, Proposed resolution;    8 Dec 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, In spec


Issue 87.1: Optional SOAP Headers (subissue: generic mechanism)

Status: resolved
In spec: No change
Date split: 7 Oct 2004
Categories: Related standards
Description: The original proposed resolution contained two parts, one that defined the generic mechanism and another that specified language for specific bindings. In order to allow us to make forward progress this subissue does not cover the section on specific bindings and instead just focusses on the mechanism. Closing this subissue vote will not close issue 87 as we will still need to decide if we wish to address any binding specific issues.
Resolution: Agreed by Web ballot (ended 24 Nov 2004)

Close with no change to the spec. The WS-BPEL TC should not standardize a way to use WSDL 1.1 web services in BPEL with the WSDL 2.0 extension for application data
Links: Proposed resolution (Yaron Y. Goland, 28 Sep 2004)     Eckenfels. Bernd, 4 Oct 2004     Yaron Y. Goland, 5 Oct 2004     Satish Thatte, 6 Oct 2004     Kristofer Agren, 6 Oct 2004     Francisco Curbera, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004         Danny van der Rijn, 6 Oct 2004     Satish Thatte, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Eckenfels. Bernd, 6 Oct 2004     Satish Thatte, 7 Oct 2004     Eckenfels. Bernd, 4 Oct 2004     Yaron Y. Goland, 5 Oct 2004     Satish Thatte, 6 Oct 2004     Kristofer Agren, 6 Oct 2004     Francisco Curbera, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Danny van der Rijn, 6 Oct 2004     Satish Thatte, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Eckenfels. Bernd, 6 Oct 2004     Satish Thatte, 7 Oct 2004     Peter Furniss, 7 Oct 2004     Yaron Y. Goland, 11 Oct 2004     Yaron Y. Goland, 11 Oct 2004     Satish Thatte, 12 Oct 2004     Web ballot (ends 09 Nov 2004)     Web ballot (ends 24 Nov 2004)     Diane Jordan, 7 Dec 2004
Changes: 7 Oct 2004 - fields: Split, Links;    12 Oct 2004 - fields: Links;    3 Nov 2004 - fields: Links;    23 Nov 2004 - fields: Status, Links;    2 Dec 2004 - fields: Status, Resolution, In spec, Proposed resolution;    8 Dec 2004 - fields: Links


Issue 88: Import Errata

Status: open
Date added: 3 Dec 2003
Categories: Syntax and validation
Date submitted: 03 December 2003
Submitter: Yaron Goland
Document: Main Spec
Description:

Should we use the XML element name 'import'?
Import implies that the files that are being pointed to are included in the BPEL definition. But strictly speaking that isn't the case since BPEL does not support in-line WSDL or XML Schema definitions. Shouldn't the name be more descriptive, such as 'associate'?

How do we handle relative URIs in import's attributes?
What is the base URI against which the relative URIs are resolved? Should we refer to something like XML Base (http://www.w3.org/TR/xmlbase/)? Should we specify that if xmlbase isn't used then the definition of the base URI is engine specific?

What happens if an engine chooses not to honor the import?
The current text of the BPEL spec states that the BPEL engine is not required to import the files it is pointed at. But if it fails to import the files then the BPEL definition will not be complete and at some point an error is likely to happen if the imported files contained definitions necessary for the BPEL. Shouldn't a static error be thrown if an engine decides not to honor an import?

What happens if two different files import the same definition?
Is there any sort of ordering? Does the first or last definition hold? Should this always be a static error? What about collisions from implicit imports versus explicit imports? An implicit import is an import that occurs through a mechanism not specified in the BPEL file itself (e.g. how import worked before we introduced the import XML element). An explicit import is an import specified via an import XML element.
Links: Announcement, 3 Dec 2003     Ugo Corda, 4 Dec 2003     Francisco Curbera, 5 Dec 2003     Ugo Corda, 5 Dec 2003     Ugo Corda, 5 Dec 2003     Discussed at San Francisco f-t-f
Changes: 3 Dec 2003 - new issue;    4 Dec 2003 - fields: Links;    5 Dec 2003 - fields: Links;    23 Jun 2004 - fields: Links


Issue 89: Handling Unrecognized Query/Expression Languages

Status: resolved
In spec: 16 Nov 2004
Date added: 7 Jan 2004
Categories: Expressions
Date submitted: 07 January 2004
Submitter: Yaron Goland
Document: Main specification
Description: What is a BPEL engine to do if the query/expression language identifier given in queryLanguage/expressionLanguage attributes are unrecognized?
Submitter's Proposal: If the query/expression language specified in a BPEL is not supported by the BPEL engine then the BPEL engine MUST reject the BPEL.
Resolution: proposed and agreed at f-t-f, 22 Sept 2004

A static analysis requirement will be defined to ensure that a process will be rejected if query or execution language expressions are not supported. (Yaron to provide text)
Links: Announcement, 7 Jan 2004     Yaron Y. Goland, 13 Aug 2004     Alex Yiu, 17 Aug 2004     Yaron Y. Goland, 18 Aug 2004     Alex Yiu, 18 Aug 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 7 Jan 2004 - new issue;    8 Jan 2004 - fields: Links;    13 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution;    17 Nov 2004 - fields: In spec


Issue 90: Assignment of external data into a variable

Status: resolved
In spec: no change
Date added: 9 Jan 2004
Categories: Data handling, Correlation
Date submitted: 09 January 2004
Submitter: Kristofer Agren
Document: BPEL specification
Description: The current assignment model allows for assigning literal data entered in directly under the <from> element. In practice, it may be desirable to have an external file/location where the data is maintained, which will allow for reuse if the same set of data is to be utilized in different business processes. The external file must be a valid XML document.
Revisitable: Yes
Submitter's proposal: I propose that this is solved by adding another form of the <form> element that can accept an external location uri and an optional query string:

<assign>
	<copy>
		<from location="uri" query="queryString"?/>
		<to.../>
	</copy>
</assign>

Resolution: Proposal in Kristofer Agren, 23 Apr 2004 REJECTED, close with no change decided at 28 April conf call

Close with no change, but mark as revisitable
Links: Announcement, 9 Jan 2004     Ugo Corda, 9 Jan 2004     Kristofer Agren, 9 Jan 2004     Ugo Corda, 9 Jan 2004     Ron Ten-Hove, 9 Jan 2004     Kristofer Agren, 9 Jan 2004     Edwin Khodabakchian, 9 Jan 2004     Kristofer Agren, 9 Jan 2004     David RR Webber, 9 Jan 2004     Eckenfels. Bernd, 12 Jan 2004     Kristofer Agren, 12 Jan 2004     Yaron Goland, 13 Jan 2004     Ugo Corda, 13 Jan 2004     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Kristofer Agren, 23 Apr 2004)     Dieter Koenig1, 26 Apr 2004     Martin Chapman, 26 Apr 2004     Edwin Khodabakchian, 26 Apr 2004     Kristofer Agren, 26 Apr 2004     Kristofer Agren, 26 Apr 2004     Alex Yiu, 26 Apr 2004     Kristofer Agren, 27 Apr 2004     David RR Webber, 27 Apr 2004     Dieter Koenig1, 27 Apr 2004     Kristofer Agren, 28 Apr 2004     Satish Thatte, 28 Apr 2004     Satish Thatte, 28 Apr 2004     David RR Webber, 28 Apr 2004
Changes: 9 Jan 2004 - new issue;    9 Jan 2004 - fields: Links;    12 Jan 2004 - fields: Links;    13 Jan 2004 - fields: Links;    22 Apr 2004 - fields: Links;    23 Apr 2004 - fields: Links, Status, Proposed resolution;    26 Apr 2004 - fields: Links;    27 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links, Status, Proposed resolution, Resolution, Revisitable


Issue 91: Nested Activities in Abstract Processes

Status: resolution proposed
Date added: 22 Jan 2004
Categories: Abstract processes
Date submitted: 21 January 2004
Submitter: Dieter Koenig1
Document: BPEL4WS 1.1 (May 5, 2003)
Description: In abstract processes, one may want to hide the internals of pick/onMessage, eventHandlers/onEvent, and onAlarm elements.

Example:

   <pick>
      <onMessage partnerLink="pl1" portType="mypt" operation="myop">
         <flow>...</flow>
      </onMessage>
      <onAlarm for="P1M">
         <sequence>...</sequence>
      </onAlarm>
   </pick>

Currently, the nested activities must be replaced by an explicit <empty> because the schema requires a nested activity.

Example:

   <pick>
      <onMessage partnerLink="pl1" portType="mypt" operation="myop">
         <empty/>
      </onMessage>
      <onAlarm for="P1M">
         <empty/>
      </onAlarm>
   </pick>
Submitter's proposal: Allow to omit the nested activity of pick/onMessage, eventHandlers/onEvent, and onAlarm in abstract processes. New syntax - added '?' after "activity" (4 times):

   <pick createInstance="yes|no"? standard-attributes>
        standard-elements
        <onMessage partnerLink="ncname" portType="qname"
             operation="ncname" variable="ncname"?>+
            <correlations>?
                <correlation set="ncname" initiate="yes|no"?/>+
           </correlations>
           activity?
       </onMessage>
       <onAlarm (for="duration-expr" | until="deadline-expr")>*
            activity?
       </onAlarm>
   </pick>

<eventHandlers>?        <!-- there must be at least one onEvent or onAlarm handler -->         <onEvent partnerLink="ncname" portType="qname"              operation="ncname" messageType="qname"              variable="ncname">*             <correlations>?                <correlation set="ncname" initiate="yes|no"/>+             </correlations>             activity?         </onEvent>         <onAlarm for="duration-expr"? until="deadline-expr"?>*              activity?         </onAlarm> </eventHandlers>


Proposed resolution: Dieter Koenig1, 19 Feb 2004
Vote announcement: waiting on issue 107
Links: Announcement, 22 Jan 2004     Proposed resolution (Dieter Koenig1, 19 Feb 2004)     Ivana Trickovic, 3 Mar 2004
Changes: 22 Jan 2004 - new issue;    22 Jan 2004 - fields: Links;    19 Feb 2004 - fields: Links, Status, Proposed resolution;    3 Mar 2004 - fields: Links;    29 Apr 2004 - fields: Vote announcement

Issue 92: Mandatory & Optional BPEL Extensibility

Status: resolution proposed
Date added: 22 Jan 2004
Categories: Syntax and validation
Date submitted: 21 January 2004
Submitter: Yaron Goland
Description: Spec - Main

BPEL provides for extension points but does not provide guidance on how they should be used. This brings up a number of issues:

  1. If the extension is optional, that is, it can be ignored if it is not understood, how should it be marked? If the extension is mandatory, that is, the BPEL MUST NOT be processed if the extension is not understood, then how should the extension be marked?

  2. Should any mandatory extensions be declared at the top of the BPEL file? The example that motivated this question is related to query and expression languages. For example, imagine that one has a BPEL where all the queries but one use the globally set query language. One particular query, buried many levels deep, overrides the default. It would be hard for a reader of the BPEL program to know the override was there and it would require that a BPEL engine do quite a bit of processing before hitting the override and realizing, for example, that it doesn't support the specified language and so must reject the BPEL. So one could imagine an up front declaration that says "here is a list of URIs that identify what mandatory extensions and query/expression languages I use."

Proposed resolution: Dieter Koenig1, 21 Dec 2004
Links: Announcement, 22 Jan 2004     Discussed at San Francisco f-t-f     possible example extension in issue 106     Proposed resolution (Dieter Koenig1, 21 Dec 2004)     Alex Yiu, 22 Dec 2004     Dieter Koenig1, 3 Jan 2005     Alex Yiu, 3 Jan 2005
Changes: 22 Jan 2004 - new issue;    22 Jan 2004 - fields: Links;    23 Jun 2004 - fields: Links;    21 Dec 2004 - fields: Links, Status, Proposed resolution;    23 Dec 2004 - fields: Links;    3 Jan 2005 - fields: Links

Issue 93: Use of XML types in faults

Status: resolved
Date added: 22 Jan 2004
Categories: Fault handling
Date submitted: 21 January 2004
Submitter: Satish Thatte
Description: We need to clarify whether variables of XML type can be used in throw statements and if so how faultHandlers catch such faults. This is currently underspecified, and the resolution of Issue 68 makes it more important to resolve this since we now mandate message types exclusively for fault variables.
Resolution: Proposed in Yaron Y. Goland, 10 Dec 2004, decided at Hawthorne face-to-face

Changes Required: Add a faultElement attribute for use with catch.

Change Since Previous Proposal: Removed the faultType attribute. Throwing complex types as faults is vaguely odd and WS-I requires that all SOAP faults be defined using elements so in general Web Services faults are typically elements anyway.

Sections 6.2, 11.3 and 13.4

Change schema from:

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

Section 13.4

From: The faultMessageType is technically redundant when the faultName used is derived from a WSDL 1.1 fault message defined as a fault response to a synchronous operation, since the WSDL fault response has a defined message type. The faultMessageType is technically redundant when the faultName used is derived from a WSDL 1.1 fault message defined as a fault response to a synchronous operation, since the WSDL fault response has a defined message type. However, the faultName may reflect a purely internal custom fault in a process, or the faultName may be missing. In such cases, the faultVariable, which is local to the fault handler and declared by its occurrence in the catch element, will not have a defined type. To avoid this possibility, although the faultName, faultVariable and faultMessageType attributes are all optional, the faultVariable and faultMessageType declarations go together, i.e., they must either both be present or both absent. Moreover, the faultName and faultVariable attributes cannot both be absent.

To: Data thrown with a fault can be a WSDL message type or a XML schema element. Each catch which specifies a faultName can only catch a fault of a single type. This one-to-one relationship is necessary in order to guarantee proper typing. If the data to be caught is a WSDL message type then the faultMessageType attribute MUST be used to specify the message type&#x2019;s qname. If the data to be caught is a XML element definition then the faultElement attribute MUST be used to specify the element definition&#x2019;s qname.

The faultName may reflect a purely internal custom fault in a process, or the faultName may be missing. In such cases, the faultVariable, which is local to the fault handler and declared by its occurrence in the catch element, will not have a defined type. To avoid this possibility faultVariable MUST only be used if either the faultMessageType or faultElement attributes, but not both, accompany it. faultMessageType and faultElement MUST NOT be used unless accompanied by faultVariable.

From: If the fault has associated fault data, a catch activity specifying a matching faultName value and a faultVariable whose type (WSDL message type) matches the type of the fault&#x2019;s data will be selected if present.

To: If the fault has associated fault data, a catch activity specifying a matching faultName value and a faultVariable whose type matches the type of the fault&#x2019;s data will be selected if present.

Section C

From:

     <complexType name="tCatch">
         <complexContent>
             <extension base="bpws:tActivityOrCompensateContainer">
                 <attribute name="faultName" type="QName"/>
                 <attribute name="faultVariable" type="NCName"/>
                 <attribute name="faultMessageType" type="QName"/>
             </extension>
         </complexContent>
     </complexType>
To:
     <complexType name="tCatch">
         <complexContent>
             <extension base="bpws:tActivityOrCompensateContainer">
                 <attribute name="faultName" type="QName"/>
                 <attribute name="faultVariable" type="NCName"/>
                 <attribute name="faultMessageType" type="QName"/>
                 <attribute name="faultElement" type="QName"/>
             </extension>
         </complexContent>
     </complexType>

Links: Announcement, 22 Jan 2004     Proposed resolution (Yaron Y. Goland, 9 Dec 2004)     Proposed resolution (Yaron Y. Goland, 10 Dec 2004)     Yaron Y. Goland, 10 Dec 2004
Changes: 22 Jan 2004 - new issue;    22 Jan 2004 - fields: Links;    10 Dec 2004 - fields: Links, Status, Proposed resolution;    11 Dec 2004 - fields: Links;    14 Dec 2004 - fields: Status, Proposed resolution, Resolution

Issue 94: Allow both "compensate" and other activities in compensation or fault handler

Status: resolved
In spec: 1.35, 30 June 2004
Date added: 2 Feb 2004
Categories: Compensation
Date submitted: 28 January 2004
Submitter: Ugo Corda
Description: The BPEL Schema only allows a single activity to be specified within a compensation handler or a catch clause in a fault handler. In case multiple activities need to be specified, they can grouped together under a "group" activity like <sequence> or <flow>. But that still does not allow mixing "compensate" with other activities, because the current syntax of sequence, flow, etc. exclude the presence of "compensate" among its children.
Resolution: Proposed in Alex Yiu, 8 Apr 2004, decided at 14 April conf call

  1. Adding compensate to group "activity"
  2. merge tActivityContainer and tActivityOrCompensateContainer.
    (by making tActivityOrCompensateContainer extended from tActivityContainer without adding any new declaration.)
    [That means: tActivityContainer by XSD itself now allows compensate activity. ]
  3. Currently, section 6.2 already included "compensate".
    1. We should add a note there to state compensate can only be used within FaultHandler and CompensateHander.
    2. A similar annotation / documentation should be added group "activity" in the XML Schema itself to state that "compensate" should be within tActivityOrCompensateContainer. (i.e. within a fault handler or compensation handler)

Links: Ugo Corda, 28 Jan 2004     Chris Keller, 28 Jan 2004     Satish Thatte, 1 Feb 2004     Satish Thatte, 1 Feb 2004     Announcement, 2 Feb 2004     Proposed resolution(Alex Yiu, 8 Apr 2004)     Ugo Corda, 8 Apr 2004     Alex Yiu, 8 Apr 2004     Discussed at Walldorf f-t-f (document details)     Discussed at 14 April con call (document details)     Alex Yiu, 22 Apr 2004
Changes: 2 Feb 2004 - new issue;    2 Feb 2004 - fields: Links;    25 Mar 2004 - fields: Title;    8 Apr 2004 - fields: Links;    9 Apr 2004 - fields: Links;    14 Apr 2004 - fields: Status, Proposed resolution;    22 Apr 2004 - fields: Status, Proposed resolution, Resolution, Links;    15 Jul 2004 - fields: In spec

Issue 95: Rethrow a Fault

Status: resolved
In spec: 4 June 2004
Date added: 3 Feb 2004
Categories: Fault handling, Compensation
Date submitted: 03 February 2004
Submitter: Dieter Koenig
Document: BPEL4WS 1.1 (May 5, 2003)
Description: A <catchAll> fault handler cannot rethrow the fault it has caught. Implicit fault handlers always rethrow the fault. Therefore, one cannot express the default behavior in a catchAll fault handler.

Specific fault handlers that catch a particular fault can rethrow the fault because they have the fault name and variable. However, a catchAll cannot because it does not know about the details of the fault.

A similar consideration applies to <catch> fault handlers that are able to accept different faults because they do not specify faultName AND faultVariable.
Submitter's proposal: Allow all fault handlers to rethrow the original fault. For example, this could be done by invoking <throw/> without attributes which would then mean that the original fault is rethrown.

Example:

   <catchAll>
      <sequence>
         ...
         <throw/> <!-- this is a rethrow of the original fault -->
      </sequence>
   <catchAll>

Resolution: Proposed in Dieter Koenig1, 19 Feb 2004, modified in later email discussion, decided at conference call 3 March 2004

Allow all custom fault handlers to rethrow the original fault with the syntax

   <rethrow/>

rethrow has no attributes.
Rationale: Default fault handlers, in addition to other steps, rethrow the original fault. Custom fault handlers must be able to express the default behavior as well.

Example:

   <catchAll>
      <sequence>
         ...
         <rethrow/> <!-- this is a rethrow of the original fault -->
      </sequence>
   <catchAll>

<catch faultVariable="xxx" faultMessageType="yyy"> also needs this construct.

Since rethrow only appears within the scope of a fault handler, it will always be unambiguous at runtime which fault is to be rethrown.
Links: Announcement, 3 Feb 2004     Proposed resolution (Dieter Koenig1, 19 Feb 2004)     Alex Yiu, 2 Mar 2004     Yaron Y. Goland, 2 Mar 2004     Dieter Koenig1, 3 Mar 2004     Alex Yiu, 3 Mar 2004     confirmation of change (Dieter Koenig1, 3 Mar 2004)
Changes: 3 Feb 2004 - new issue;    3 Feb 2004 - fields: Links;    19 Feb 2004 - fields: Links, Status, Proposed resolution;    3 Mar 2004 - fields: Links, Status, Proposed resolution, Resolution, Rationale;    4 Mar 2004 - fields: Links;    9 Jun 2004 - fields: In spec


Issue 96: Engine-managed correlation sets

Status: open
Date added: 3 Feb 2004
Categories: Correlation
Date submitted: 03 February 2004
Submitter: Yaron Goland
Document: Spec - Main
Description: When a BPEL programmer wants to use correlation they define a correlation set which consists of a series of properties. The BPEL programmer then makes sure that when initializing a correlation set the message being used for initialization has the proper values, IDs, etc., inside of it. This is a powerful generic feature that allows BPEL to work with a wide variety of correlation mechanisms. However, protocols are now being introduced to explicitly manage message correlation, for example, ws-addressing. One of the benefits of such protocols is that they free the programmer from having to worry about the details of correlation set definition and value creation. Therefore it would be extremely useful if BPEL, in addition to its existing correlation set mechanism, introduced the ability to define an 'opaque' correlation set. That is, a correlation set whose definition and associated message values are managed by the BPEL engine. An opaque correlation set would only define what protocol it is based on and leave the other details to the BPEL engine. E.g. <correlationSet name="myCor" algorithm="http://somestandards.org/astandard/mechanism"/>
Links: Announcement, 3 Feb 2004     Frank Leymann, 4 Feb 2004     Peter Furniss, 20 Feb 2004     Monica J. Martin, 4 Mar 2004     Ugo Corda, 4 Mar 2004     Satish Thatte, 6 Mar 2004     Ugo Corda, 6 Mar 2004     issue 123 : Matching <reply> with <receive>     issue 118 : When are Correlation Sets Mandatory?
Changes: 3 Feb 2004 - new issue;    4 Feb 2004 - fields: Links;    23 Feb 2004 - fields: Links;    4 Mar 2004 - fields: Links;    6 Mar 2004 - fields: Links;    18 Mar 2004 - fields: Title;    22 Jun 2004 - fields: Links

Issue 97: Optional Variable References in Abstract Processes

Status: resolution proposed
Date added: 10 Feb 2004
Categories: Abstract processes
Date submitted: 10 February 2004
Submitter: Dieter Koenig
Document: BPEL4WS 1.1 (May 5, 2003) and WSBPEL Working Draft 1 (Nov 23, 2003)
Description: Section 15.1. has a statement about making variable references optional in abstract processes: "To simplify these common cases it is permissible, in abstract processes, to omit the variable reference attributes from the <invoke/>, <receive/>, and <reply/> activities."

Consequently, for abstract processes, these references must also be optional in the <onMessage> and <onEvent> elements.
Submitter's proposal: For abstract processes, make variable references optional in the <onMessage> and <onEvent> elements.
Proposed resolution: Dieter Koenig1, 19 Feb 2004
Vote announcement: waiting on issue 107
Links: Announcement, 10 Feb 2004     Ivana Trickovic, 10 Feb 2004     Proposed resolution (Dieter Koenig1, 19 Feb 2004)     Alex Yiu, 19 Feb 2004     Dieter Koenig1, 19 Feb 2004     Alex Yiu, 19 Feb 2004     Monica J. Martin, 26 Feb 2004
Changes: 10 Feb 2004 - new issue;    11 Feb 2004 - fields: Links;    19 Feb 2004 - fields: Links, Status, Proposed resolution;    20 Feb 2004 - fields: Links;    26 Feb 2004 - fields: Links;    29 Apr 2004 - fields: Vote announcement


Issue 98: What version number are we working towards

Status: resolved
In spec: 19 Nov 2004
Date added: 20 Feb 2004
Categories: Specification editing
Date submitted: 20 February 2004
Submitter: Peter Furniss
Description: What will be the version number of our current output ? We sometimes need to refer to that as distinct from potential future versions but stating this is cumbersome because our current target doesn't have an obvious name.

Version 1.0 was the August 2002 text; our input document is 1.1. "OASIS TC 1.0" has been used, but a simpler monotonic numbering would seem easier to follow.
Resolution: Agreed by multiple choice web ballot first (ended 14 Sep 2004) , second (ended 14 Sep 2004) , third (ended 14 Sep 2004) , announced result

The name will be WS-BPEL v2.0
Links: Announcement, 20 Feb 2004     Peter Furniss, 9 Jun 2004     Yaron Y. Goland, 9 Nov 2004
Changes: 20 Feb 2004 - new issue;    23 Feb 2004 - fields: Links;    9 Jun 2004 - fields: Links;    10 Nov 2004 - fields: Links;    11 Nov 2004 - fields: Status, Resolution;    19 Nov 2004 - fields: In spec


Issue 99: Triggering activities for abstract processes

Status: resolution proposed
Date added: 3 Mar 2004
Categories: Abstract processes
Date submitted: 03 March 2004
Submitter: Ivana Trickovic
Description: The current version (BPEL4WS v1.1, May 2003) specifies that each process (either executable or abstract) must contain at least one "start activity" (start activity is either a receive activity or a pick activity that receives a message and is annotated with the createInstance attribute set to "yes" to indicate that the occurrence of that activity causes a new instance of the process to be created).

This restriction makes less sense for BPEL abstract processes. Because of this restriction, the abstract process of the party that initiates a message exchange must be extended and a start activity must be introduced (also additional WSDL elements, such as port types, messages, must be defined as well as partner link type). But how the initiating process is started is an implementation detail and does not have to be included in the BPEL abstract process since it is not part of the "business protocol".

Submitter's proposal: Allow the invoke activity to be used as the start activity for abstract processes.
Proposed resolution: Ivana Trickovic, 10 Mar 2004
Vote announcement: waiting on issue 107
Links: Announcement, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     Ivana Trickovic, 4 Mar 2004     Danny van der Rijn, 4 Mar 2004     Satish Thatte, 6 Mar 2004     Ivana Trickovic, 9 Mar 2004     Proposed resolution (Ivana Trickovic, 10 Mar 2004)     Yaron Y. Goland, 12 Mar 2004     Ivana Trickovic, 15 Mar 2004     Yaron Y. Goland, 5 May 2004     Alex Yiu, 6 May 2004     Alex Yiu, 6 May 2004     Ivana Trickovic, 7 May 2004     Yaron Y. Goland, 10 May 2004     Yaron Y. Goland, 10 May 2004     Ivana Trickovic, 12 May 2004     Yaron Y. Goland, 17 May 2004     Ivana Trickovic, 21 May 2004     Yaron Y. Goland, 21 May 2004     Ivana Trickovic, 26 May 2004     msg on abstract list (Diane Jordan, 4 Jun 2004)     issue 99 explanation from the previous link (document details)     uddi and bpel4ws document referred to in the previous link (document details)     Peter Furniss, 23 Jun 2004
Changes: 3 Mar 2004 - new issue;    3 Mar 2004 - fields: Links;    4 Mar 2004 - fields: Links;    6 Mar 2004 - fields: Links;    9 Mar 2004 - fields: Links;    10 Mar 2004 - fields: Links, Status, Proposed resolution;    13 Mar 2004 - fields: Links;    15 Mar 2004 - fields: Links;    29 Apr 2004 - fields: Vote announcement;    6 May 2004 - fields: Links;    8 May 2004 - fields: Links;    11 May 2004 - fields: Links;    15 May 2004 - fields: Links;    17 May 2004 - fields: Links;    21 May 2004 - fields: Links;    27 May 2004 - fields: Links;    23 Jun 2004 - fields: Links


Issue 100: When should XML be validated?

Status: resolved
In spec: No change
Date added: 4 Mar 2004
Categories: Syntax and validation, Data handling
Date submitted: 03 March 2004
Submitter: Danny van der Rijn
Description: There has been some discussion of when XML should be validated. This is especially relevant in the incremental build-out cases, one of which is {while+invoke+receive+assign}.
Resolution: Proposed verbally and decided at San Francisco f-t-f

Closed with no change to the spec.
Rationale: In the present (1.34 or earlier) spec, there is no possibility that a valid XML document manipulated by a BPEL process can become invalid.

Some currently open issues might change this - the resolution of such issues needs to take account of the possibility of temporary invalidation. Identified issues are issue 11 : Query in <to> close should allow assigning to new locations , issue 51 : Section 9.3.1 & Schema Validation and issue 103 : Standardizing $varName syntax for XPath to refer to a BPEL variable .
Links: Announcement, 4 Mar 2004     Discussed at Walldorf f-t-f (document details)
Changes: 4 Mar 2004 - new issue;    4 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links;    23 Jun 2004 - fields: Status, Resolution, In spec, Rationale


Issue 101: Local variables overriding enclosing scope

Status: resolved
In spec: 4 June 2004
Date added: 5 Mar 2004
Categories: Scopes, Data handling
Date submitted: 04 March 2004
Submitter: Danny van der Rijn
Description: in 9.2, it says: "It is not permitted to have variables with same name but different messageType/type/element within an enclosing scope hierarchy." This seems to be unnecessarily restrictive, and inconsistent with scoping behavior in other languages.
Submitter's proposal: remove the restriction
Resolution: Proposed in Danny van der Rijn, 31 Mar 2004, decided at 28 April conf call

remove the following from 9.2:

It is not permitted to have variables with same name but different messageType/type/element within an enclosing scope hierarchy.

add the following:

Variable access follows common lexical scoping rules. A variable resolves to the nearest enclosing scope, regardless of the type of the variable.

Links: Danny van der Rijn, 3 Mar 2004     Ugo Corda, 3 Mar 2004     Danny van der Rijn, 3 Mar 2004     Ugo Corda, 4 Mar 2004     Yuzo Fujishima, 4 Mar 2004     Yaron Y. Goland, 4 Mar 2004     Chris Keller, 4 Mar 2004     Danny van der Rijn, 4 Mar 2004     Announcement, 5 Mar 2004     Proposed resolution (Danny van der Rijn, 31 Mar 2004)     Discussed at Walldorf f-t-f (document details)
Changes: 5 Mar 2004 - new issue;    5 Mar 2004 - fields: Links;    31 Mar 2004 - fields: Links, Status, Proposed resolution;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec

Issue 102: Fixing Typos in getVariable*() in BPEL examples

Status: open
Date added: 9 Mar 2004
Categories: Data handling
Date submitted: 08 March 2004
Submitter: Alex Yiu
Description: There seem to be typos in our BPEL examples
"bpws:getVariableProperty(stockResult,level) > 100"
"bpws:getVariableProperty(stockResult,level) >= 0"
"bpws:getVariableData(orderDetails) > 100"

We need to put quotations on function parameters.

It becomes like:

"bpws:getVariableProperty('stockResult','level') > 100"
"bpws:getVariableProperty('stockResult','level') >= 0"
"bpws:getVariableData('orderDetails') > 100"

In some of the examples the "bpws:" is actually extra and incorrect. The prefix-namespace mapping of a function call in XPath typically inherited from that of the hosting element.
Links: Announcement, 9 Mar 2004     Ron Ten-Hove, 9 Mar 2004     Alex Yiu, 9 Mar 2004     Chris Keller, 17 Mar 2004     Announcement, Wed Mar 17 10:59:27 2004     Alex Yiu, 17 Mar 2004     Discussed at Walldorf f-t-f (document details)
Changes: 9 Mar 2004 - new issue;    9 Mar 2004 - fields: Links;    10 Mar 2004 - fields: Links;    17 Mar 2004 - fields: Links;    22 Apr 2004 - fields: Links


Issue 103: Standardizing $varName syntax for XPath to refer to a BPEL variable

Status: resolution proposed
Date added: 9 Mar 2004
Categories: Data handling
Date submitted: 08 March 2004
Submitter: Alex Yiu
Description:

Right now, there are three BPWS functions defined in BPEL can be called in an XPath Query / Expression.

bpws:getVariableProperty ('variableName', 'propertyName')
bpws:getVariableData ('variableName', 'partName'?, 'locationPath'?)
bpws:getLinkStatus('linkName')
  
For refering to a variable data, if data is of an XSD complex type or XSD simple type (not WSDL 1.1 type), we want to add one more way to refer to a variable on top of getVariableData() Function Call? That is using "$varName" syntax.

Currently, we have:
"bpws:getVariableData(orderDetails) > 100"
The additional way will look like:
"$orderDetails > 100"
Note that:
References:
http://www.w3.org/TR/xpath#NT-FunctionCall
http://www.w3.org/TR/xpath#NT-VariableReference
Proposed resolution: Yaron Y. Goland, 17 Sep 2004
Links: Announcement, 9 Mar 2004     Yaron Y. Goland, 11 Mar 2004     Kristofer Agren, 11 Mar 2004     Alex Yiu, 11 Mar 2004     Satish Thatte, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Satish Thatte, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Satish Thatte, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Ugo Corda, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Ugo Corda, 12 Mar 2004     Ugo Corda, 12 Mar 2004     Ugo Corda, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Assaf Arkin, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Satish Thatte, 12 Mar 2004     Dieter Roller, 12 Mar 2004     Maciej Szefler, 12 Mar 2004     Satish Thatte, 12 Mar 2004     Danny van der Rijn, 12 Mar 2004     Maciej Szefler, 12 Mar 2004     Danny van der Rijn, 12 Mar 2004     Maciej Szefler, 12 Mar 2004     Danny van der Rijn, 12 Mar 2004     Ron Ten-Hove, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Alex Yiu, 12 Mar 2004     Maciej Szefler, 12 Mar 2004     Maciej Szefler, 12 Mar 2004     Alex Yiu, 13 Mar 2004     Alex Yiu, 15 Mar 2004     Yaron Y. Goland, 18 Mar 2004     Alex Yiu, 9 Apr 2004     Discussed at Walldorf f-t-f (document details)     Alex Yiu, 28 Apr 2004     Alex Yiu, 3 May 2004     Yaron Y. Goland, 4 May 2004     Danny van der Rijn, 4 May 2004     Alex Yiu, 4 May 2004     Alex Yiu, 4 May 2004     Danny van der Rijn, 4 May 2004     Alex Yiu, 5 May 2004     Ugo Corda, 7 May 2004     Ugo Corda, 7 May 2004     Alex Yiu, 7 May 2004     Ugo Corda, 7 May 2004     Ugo Corda, 7 May 2004     Alex Yiu, 7 May 2004     Yaron Y. Goland, 10 May 2004     Alex Yiu, 11 May 2004     see rationale in issue 100     Eckenfels. Bernd, 29 Jul 2004     Alex Yiu, 25 Aug 2004     Ugo Corda, 25 Aug 2004     Alex Yiu, 25 Aug 2004     Ugo Corda, 25 Aug 2004     Alex Yiu, 25 Aug 2004     Proposed resolution (Yaron Y. Goland, 17 Sep 2004)     Satish Thatte, 24 Sep 2004     Ugo Corda, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Ugo Corda, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Assaf Arkin, 24 Sep 2004     Assaf Arkin, 24 Sep 2004     Ugo Corda, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Ugo Corda, 24 Sep 2004     Yaron Y. Goland, 25 Sep 2004     Alex Yiu, 25 Sep 2004     Danny van der Rijn, 27 Sep 2004     Chris Keller, 27 Sep 2004     Alex Yiu, 27 Sep 2004     Satish Thatte, 27 Sep 2004     Yaron Y. Goland, 28 Sep 2004     Francisco Curbera, 28 Sep 2004     Yaron Y. Goland, 28 Sep 2004     Satish Thatte, 29 Sep 2004     Yaron Y. Goland, 29 Sep 2004     Alex Yiu, 30 Sep 2004     Satish Thatte, 30 Sep 2004     Francisco Curbera, 30 Sep 2004
Changes: 9 Mar 2004 - new issue;    9 Mar 2004 - fields: Links;    13 Mar 2004 - fields: Links;    16 Mar 2004 - fields: Links;    18 Mar 2004 - fields: Links;    10 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    3 May 2004 - fields: Links;    5 May 2004 - fields: Links;    7 May 2004 - fields: Links;    8 May 2004 - fields: Links;    11 May 2004 - fields: Links;    12 May 2004 - fields: Links;    23 Jun 2004 - fields: Links;    30 Jul 2004 - fields: Links;    26 Aug 2004 - fields: Links;    17 Sep 2004 - fields: Links, Status, Proposed resolution;    24 Sep 2004 - fields: Links;    25 Sep 2004 - fields: Links;    27 Sep 2004 - fields: Links;    28 Sep 2004 - fields: Links;    29 Sep 2004 - fields: Links;    30 Sep 2004 - fields: Links

Issue 104: incorrect target link names in 12.5.3. Flow Graph

Status: resolved
In spec: 4 June 2004
Date added: 10 Mar 2004
Categories: Specification editing
Date submitted: 10 March 2004
Submitter: Yuzo Fujishima
Document: wsbpel-specification-draft-Nov2303.htm
Description: Incorrect link names are used in 12.5.3. Flow Graph Example. As shown in the following code snippet, incorrect link names, i.e., "getBuyerInformation" and "getSellerInformation", are used.
       <invoke name="settleTrade"
               joinCondition="bpws:getLinkStatus('buyToSettle') and
               bpws:getLinkStatus('sellToSettle')">
             <target linkName="getBuyerInformation"/>
             <target linkName="getSellerInformation"/>
             <source linkName="toBuyConfirm"/>
             <source linkName="toSellConfirm"/>
        </invoke>

Qualifier: typo
Champions: Yuzo Fujishima fujishima@bc.jp.nec.com
Submitter's Proposal: Replace "getBuyerInformation" and "getSellerInformation" with "buyToSettle" and "sellToSettle", respectively.
Resolution: Proposed in Yuzo Fujishima, 11 Mar 2004, decided at conf call 17 March 2004

In 12.5.3. Flow Graph Example, replace "getBuyerInformation" and "getSellerInformation" with "buyToSettle" and "sellToSettle", respectively.
Links: Announcement, 10 Mar 2004     Proposed resolution (Yuzo Fujishima, 11 Mar 2004)
Changes: 10 Mar 2004 - new issue;    10 Mar 2004 - fields: Links;    11 Mar 2004 - fields: Links, Status, Proposed resolution;    17 Mar 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec


Issue 105: XML namespaces used in spec and examples need to be defined

Status: resolved
Date added: 17 Mar 2004
Categories: Specification editing
Date submitted: 16 March 2004
Submitter: Ron Ten-Hove
Description: The specification, including examples, makes use of various XML prefixes without always clearly defining them. This has lead to some confusion during discussions on the [wsbpel-implement] list, and will doubtless confuse some readers of the final specification if this is not addressed in some fashion.
Submitter's proposal: A possible solution is to include a table of prefixes used within the document, and the name space URIs to which they are assigned, in the introductory material at the beginning of the specification (perhaps section 2, Notational Conventions). (This has become a common practice in other XML-based specifications that make use of multiple XML name spaces.)
Resolution: Proposed in Ron Ten-Hove, 4 Jun 2004, decided at San Francisco f-t-f

Include a table of prefixes used within the document, and the name space URIs to which they are assigned, in section 2, Notational Conventions.
Links: Announcement, 17 Mar 2004     Proposed resolution (Ron Ten-Hove, 4 Jun 2004)
Changes: 17 Mar 2004 - new issue;    17 Mar 2004 - fields: Links;    9 Jun 2004 - fields: Links, Status, Proposed resolution;    24 Jun 2004 - fields: Status, Proposed resolution, Resolution


Issue 106: ASSERT activity.

Status: resolved
In spec: No change
Date added: 18 Mar 2004
Categories: Syntax and validation
Date submitted: 18 March 2004
Submitter: Maciej Szefler
Description: I'd like to propose the addition of an assertion facility to the BPEL language. Specifically I'd like to see <precondition> and <postcondition> elements added to the list of standard elements, something along the lines of:
  <any-activity>
     <precondition>
	    <expression language="XPath">
	       some-xpath-expression
	    </expression>
     </precondition>
     <postcondition>
	    <expression language="XPath">
	       some-xpath-expression
	    </expression>
     </postcondition>

	....

  </any-activity>
Interpetation of the <pre-/post-condition> elements would be optional, but if assertions are enabled the expressions must evaluate to "true" or else the process instance is immediately terminated (ala <terminate>). Assertions would be available to both executable and abstract processes. -standard argument for assertions goes here-.
Resolution: Proposed verbally and decided at San Francisco f-t-f

Closed with no change to the spec.
Rationale: Since an assertion would not need to be evaluated and the semantics would be implementation defined, it is considered appropriate for an extension (see issue 92 : Mandatory & Optional BPEL Extensibility ).
Links: Announcement, 18 Mar 2004     Ricky Ho, 18 Mar 2004     Danny van der Rijn, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Ricky Ho, 18 Mar 2004     Chris Keller, 18 Mar 2004     Satish Thatte, 18 Mar 2004     David RR Webber, 18 Mar 2004     Maciej Szefler, 18 Mar 2004     Ricky Ho, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Satish Thatte, 18 Mar 2004     Maciej Szefler, 18 Mar 2004     Satish Thatte, 18 Mar 2004
Changes: 18 Mar 2004 - new issue;    18 Mar 2004 - fields: Links;    19 Mar 2004 - fields: Links;    23 Jun 2004 - fields: Status, Resolution, In spec, Rationale


Issue 107: Opacity and the meaning of nothingness in abstract processes

Status: resolution proposed
Date added: 18 Mar 2004
Categories: Abstract processes
Date submitted: 18 March 2004
Submitter: Yaron Y. Goland
Description: The design of abstract processes requires the ability to omit information that is not relevant to the abstract process's design. There are two general strategies for omitting information - implicit and explicit.

An example of implicitly hiding data is the way that abstract processes deal with some of the variables on message operations. If one doesn't want to specify where a message is recorded on a receive then one may simply leave off the variable attribute.

An example of explicitly hiding data would be introducing something like an <opaque> activity. For example, imagine that one is defining an abstract process and the start activities of the abstract process are to be omitted since they are not relevant to the functionality the abstract process is describing. In that case one could start a process with an <opaque> activity. By putting in <opaque> one is explicitly communicating to the reader of the abstract process 'There is something here but its definition is not relevant to the goal of the abstract process.'

The advantage of explicit versus implicit hiding is in error detection.

In an implicit system where one simply leaves off variables or omits activities there is no way to tell the difference between an error, e.g. the person intended to include the variable or activity but forget and true omission. This is a well known problem with treating the absence of information as information.

In an explicit system where one would have <opaque> activities and special reserved bpel:opaque place holders for attributes there is no possibility for confusion. If an opaque value is specified then one has an unambiguous declaration from the designer of the abstract process as to their intention.

The issue before the group is - should we consistently use an implicit or explicit omission mechanism for specifying when information has been intentionally omitted in an abstract process?
Proposed resolution: Peter Furniss, 14 Dec 2004 Danny van der Rijn, 14 Dec 2004
Links: Announcement, 18 Mar 2004     Frank Leymann, 19 Mar 2004     Yaron Y. Goland, 19 Mar 2004     Frank Leymann, 23 Mar 2004     Yaron Y. Goland, 23 Mar 2004     Satish Thatte, 24 Mar 2004     Yaron Y. Goland, 14 Apr 2004     Yuzo Fujishima, 15 Apr 2004     Philip Rossomando, 15 Apr 2004     Yaron Y. Goland, 15 Apr 2004     Yuzo Fujishima, 16 Apr 2004     Yaron Y. Goland, 16 Apr 2004     Yaron Y. Goland, 16 Apr 2004     Tony Fletcher, 17 Apr 2004     Eckenfels. Bernd, 17 Apr 2004     Yuzo Fujishima, 19 Apr 2004     Yaron Y. Goland, 19 Apr 2004     Yuzo Fujishima, 20 Apr 2004     Assaf Arkin, 20 Apr 2004     Yaron Y. Goland, 20 Apr 2004     Assaf Arkin, 22 Apr 2004     Discussed at 14 April con call (document details)     Yaron Y. Goland, 22 Apr 2004     Monica J. Martin, 23 Apr 2004     Yaron Y. Goland, 26 Apr 2004     Assaf Arkin, 28 Apr 2004     Yaron Y. Goland, 30 Apr 2004     Proposed resolution (Yaron Y. Goland, 5 May 2004)     Alex Yiu, 6 May 2004     Dieter Roller, 6 May 2004     Philip Rossomando, 7 May 2004     Alex Yiu, 8 May 2004     Alex Yiu, 8 May 2004     Yaron Y. Goland, 10 May 2004     Proposed resolution (rkhalaf, 30 Sep 2004)     Yaron Y. Goland, 5 Oct 2004     Assaf Arkin, 5 Oct 2004     Yaron Y. Goland, 6 Oct 2004     rkhalaf, 6 Oct 2004     Martin Chapman, 8 Oct 2004     Peter Furniss, 8 Oct 2004     rkhalaf, 8 Oct 2004     Yaron Y. Goland, 11 Oct 2004     rkhalaf, 11 Oct 2004     Proposed resolution (Peter Furniss, 1 Dec 2004)     [See also discussion of;ISSUE=82]     Proposed resolution (Peter Furniss, 14 Dec 2004)     Danny van der Rijn, 14 Dec 2004
Changes: 18 Mar 2004 - new issue;    18 Mar 2004 - fields: Links;    19 Mar 2004 - fields: Links;    20 Mar 2004 - fields: Links;    23 Mar 2004 - fields: Links;    24 Mar 2004 - fields: Links;    15 Apr 2004 - fields: Links;    16 Apr 2004 - fields: Links;    17 Apr 2004 - fields: Links;    19 Apr 2004 - fields: Links;    20 Apr 2004 - fields: Links;    21 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links;    24 Apr 2004 - fields: Links;    27 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    1 May 2004 - fields: Links;    6 May 2004 - fields: Links, Status, Proposed resolution;    7 May 2004 - fields: Links;    8 May 2004 - fields: Links;    11 May 2004 - fields: Links;    30 Sep 2004 - fields: Status, Proposed resolution, Links;    5 Oct 2004 - fields: Links;    6 Oct 2004 - fields: Links;    7 Oct 2004 - fields: Links;    11 Oct 2004 - fields: Links;    12 Oct 2004 - fields: Links;    2 Dec 2004 - fields: Links, Status, Proposed resolution;    14 Dec 2004 - fields: Links, Status, Proposed resolution


Issue 108: Parallel Compensation

Status: resolved
In spec: 19 Nov 04
Date added: 20 Mar 2004
Categories: Compensation
Date submitted: 19 March 2004
Submitter: Yaron Y. Goland
Description: If someone is willing to do manual compensation then they could, at least in theory, do parallel compensation today by including calls to compensate with the names of the child scopes inside of a flow. E.g.
compensationHandler
    flow
       compensate scope="foo"
       compensate scope="bar"
In the case of the default compensation handler section 13.3.3 of the latest editor's draft states "If the compensation handler for a scope is absent, the default compensation handler invokes the compensation handlers for the immediately enclosed scopes in the reverse order of the completion of those scopes."

But, if one felt deeply sneaky, one could interpret the spec to mean that one must start the compensation handlers in the completion order but there is no requirement that one must necessarily wait for a compensation handler to complete execution before starting the next one. In other words, one could interpret the current language as allowing default compensation handlers to execute child compensation handlers in parallel.

The purpose of this issue is to clarify the ability to run compensation handlers in parallel so that programmers know what to expect. Since we now allow compensation handlers to manipulate common variables it is critical that programmers know if their handlers can run in parallel.

At a minimum this issue should answer the following questions:


Proposed resolution: Yaron Y. Goland, 23 Nov 2004
Resolution: Proposed in Yaron Y. Goland, 23 Nov 2004, agreed at conf call 24 Nov 2004

The issue this addressed was resolved as part of the resolution of issue 10 : Serialization of compensation .
Links: Announcement, 20 Mar 2004     Yaron Y. Goland, 18 Mar 2004     Frank Leymann, 19 Mar 2004     Muruga Chinnananchi, 19 Mar 2004     Alastair J. Green, 30 Mar 2004     Muruga Chinnananchi, 30 Mar 2004     Muruga Chinnananchi, 31 Mar 2004     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Yaron Y. Goland, 23 Nov 2004)
Changes: 20 Mar 2004 - new issue;    20 Mar 2004 - fields: Links;    30 Mar 2004 - fields: Links;    31 Mar 2004 - fields: Links;    1 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links;    24 Nov 2004 - fields: Links, Status, Proposed resolution, Resolution, In spec


Issue 109: Compatibility between Abstract and Executable Processes

Status: open
Date added: 24 Mar 2004
Categories: Abstract processes
Date submitted: 23 March 2004
Submitter: Monica J. Martin
Document: BPEL specification
Description: In multiple issues (issue 24 : Separate schemas for executable vs abstract BPEL , issue 42 : Need for Formalism , issue 82 : description of abstract processes in spec , issue 91 : Nested Activities in Abstract Processes , issue 97 : Optional Variable References in Abstract Processes and issue 99 : Triggering activities for abstract processes , for example), we are seeing the need to be more explicit about the relationship and compatibility of abstract and executable processes. As indicated, the abstract process may be used for conformance for an executable process. In order to ensure stability for any conformance requirements (yet to be defined) and to lay the groundwork for conformance parameters that may be included in this specification, some mechanisms should be put in place to:
  1. Minimize the risk of under specification of conformance of abstract-to-executable WS-BPEL.
  2. Support type checking using the abstract process.
  3. Encourage the future specification of behavior checking.
  4. Define a mapping between the abstract and executable processes (like a template to the executable definition).
  5. Identify what other constraints may be advised to support compatibility of abstract and executable processes.
At a minimum, item [d] should be explicitly defined in the technical specification.
Links: Announcement, 24 Mar 2004     Monica J. Martin, 16 Aug 2004
Changes: 24 Mar 2004 - new issue;    24 Mar 2004 - fields: Links;    17 Aug 2004 - fields: Links

Issue 110: Issues with the Pattern Attribute

Status: open
Date added: 24 Mar 2004
Categories: Syntax and validation
Date submitted: 24 March 2004
Submitter: Yaron Y. Goland
Description: Section 10.2 of the specification currently says:
Finally, in the case of invoke, when the operation invoked is synchronous request/response, a pattern attribute is used to indicate whether the correlation applies to the outbound (request) message, the inbound (response) message, or both. These ideas are explained in more detail in the context of the use of correlation in the rest of this example.

There are several issues this text raises about the pattern attribute:

  1. The pattern attribute is intended to deal with request/response patterns but such patterns are not required to be synchronous. It is legal in WSDL 1.1 to define a request/response operation that bind to an asynchronous binding. I realize that the intent was probably to say that the behavior within BPEL (as opposed to on the wire) is synchronous but in that case the distinction needs to be made clear.

  2. I consistently get confused about what in versus out means. Why not use names that more closely match the WSDL names? E.g. something like "request | response | both"? I would extend this change to the inputvariable and outputvariable attributes renaming them responseVariable and requestVariable.

  3. The text in the referenced paragraph has caused confusion because it implies that the pattern attribute is only needed on correlation sets on request/response invokes. But we also require its use on one-ways. Ideally we would make the pattern attribute illegal on correlation sets defined on one-way Invokes and mandatory on correlation sets used on request/response Invokes. I realize that we probably can't express that restriction in XML Schema but, if so, we shouldn't allow XML Schema's limitations stop us from doing the right thing for our users.

Links: Announcement, 24 Mar 2004     Ugo Corda, 25 Mar 2004     Yaron Y. Goland, 27 Aug 2004     Danny van der Rijn, 27 Aug 2004     Ugo Corda, 27 Aug 2004     Danny van der Rijn, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Danny van der Rijn, 30 Aug 2004     Yaron Y. Goland, 10 Sep 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)     David RR Webber, 16 Sep 2004     Alex Yiu, 20 Sep 2004     Discussed on 13 Oct call, proposal withdrawn
Changes: 24 Mar 2004 - new issue;    24 Mar 2004 - fields: Links;    25 Mar 2004 - fields: Links;    27 Aug 2004 - fields: Links;    30 Aug 2004 - fields: Links;    10 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    20 Sep 2004 - fields: Links;    14 Oct 2004 - fields: Status, Links, Proposed resolution

Issue 111: Extension Activities

Status: open
Date added: 25 Mar 2004
Categories: Syntax and validation
Date submitted: 25 March 2004
Submitter: Yaron Y. Goland
Description: BPEL needs a well defined mechanism to allow for the introduction of new activity types. The current group mechanism used to define activities does not provide a well defined way to introduce extension activities.
Links: Announcement, 25 Mar 2004
Changes: 25 Mar 2004 - new issue;    25 Mar 2004 - fields: Links

Issue 112: Input/Output Elements on Messaging Activities

Status: open
Date added: 25 Mar 2004
Categories: Data handling
Date submitted: 25 March 2004
Submitter: Yaron Y. Goland
Description:

A common BPEL use case is that a programmer has a number of variables that contain data that will be used to create a message. When sending a message the programmer will create a temporary message variable, copy the values from the variables into the temporary message and then submit the temporary message variable. At which point the temporary message variable is discarded.

Similarly, when receiving a message the programmer may actually want the data in the message to be recorded in a number of variables. Currently the programmer has to create a temporary message variable, receive the message into the temporary message variable just to immediately turn around and pull the data out, record the data into individual variables and then discard the temporary message variable.

In both cases the temporary message variable is a transient storage location whose only purpose is to push data in and pull data out of message activities.

It would be extremely friendly if we could provide a macro that would allow programmers to build up a message as part of an invoke/reply from a set of variables rather than having to create a temporary variable for that purpose. Similarly, it would be great if it were possible on pick/receive to pull data directly out of an incoming message and record the data into variables rather than having to put the data into a temporary message variable whose only purpose is to get ripped to pieces.

To be clear, this is a request for a macro, not for a new BPEL feature.
Links: Announcement, 25 Mar 2004     David RR Webber, 26 Mar 2004     Eckenfels. Bernd, 23 Jun 2004
Changes: 25 Mar 2004 - new issue;    25 Mar 2004 - fields: Links;    26 Mar 2004 - fields: Links;    24 Jun 2004 - fields: Links


Issue 113: Optional Port Types

Status: resolved
In spec: No change
Date added: 25 Mar 2004
Categories: Syntax and validation
Date submitted: 25 March 2004
Submitter: Yaron Y. Goland
Description:

Currently we require that portType be specified on message activities, even though it is redundant, because it is useful for error checking. But it seems unfair to require programmers to constantly specify portType if they don't want or need the extra error checking.

As such this issue proposes that portType be made optional. If the portType attribute is specified on a message activity then the BPEL validator MUST check that the value of the portType matches the value for the relevant role in the partnerLink definition. If the specified value for portType does not match its expected value then the BPEL MUST be rejected.
Resolution: Proposed verbally and decided at San Francisco f-t-f

Closed as being duplicate of (having the same resolution as) issue 44 : portType is duplicated on Invoke activity and partnerLinkType
Links: Announcement, 25 Mar 2004
Changes: 25 Mar 2004 - new issue;    25 Mar 2004 - fields: Links;    23 Jun 2004 - fields: In spec, Resolution, Status


Issue 114: Multiple Correlation Sets

Status: resolved
In spec: 1.35, 30 June 2004
Date added: 31 Mar 2004
Categories: Correlation
Date submitted: 30 March 2004
Submitter: Dieter Koenig1
Document: BPEL4WS 1.1 (May 5, 2003), Chapter 10, "Correlation".
Description: If multiple correlation sets with initiate="no" are used in a receive or pick/onMessage activity, then it is not specified whether each one of them must resolve individually to the same process instance.
Submitter's proposal: We propose that the following clarification is added to the BPEL specification:
  1. If multiple correlation sets with initiate="no" are used in a receive or pick/onMessage, then any individually must resolve to the same process instance.
  2. The same rule applies if EPRs with Reference Properties are used to identify an instance and correlation sets are present.

Resolution: Proposed in Dieter Koenig1, 9 Jun 2004, decided at San Francisco f-t-f

  1. Add text to the specification that clarifies the semantics in presence of multiple correlation sets:
    If multiple correlation sets with initiate="no" are used in a receive, pick/onMessage, or eventHandler/onEvent, then they must all match a message for that message to be delivered to the activity in the given process instance.

  2. Ignore all references to EPRs in this issue and revisit that when 34 is resolved.

Links: Announcement, 31 Mar 2004     Proposed resolution (Dieter Koenig1, 9 Jun 2004)     Monica J. Martin, 16 Jun 2004     Monica J. Martin, 16 Jun 2004     Dieter Koenig1, 17 Jun 2004     Monica J. Martin, 17 Jun 2004
Changes: 31 Mar 2004 - new issue;    31 Mar 2004 - fields: Links;    9 Jun 2004 - fields: Links, Status, Proposed resolution;    17 Jun 2004 - fields: Links;    22 Jun 2004 - fields: Status, Proposed resolution, Resolution;    15 Jul 2004 - fields: In spec

Issue 115: Revise content of Appendix C

Status: resolved
In spec: No change
Date added: 1 Apr 2004
Categories: Compensation, State management
Date submitted: 01 April 2004
Submitter: Satish Thatte
Description: As a part of the recommended resolution of issues issue 30 : Support for coordination protocol , issue 53 : Include Business Transaction Management (BTM) constructs ,54-59, the F2F meeting recommended removing the current Appendix C which appears to take a hard dependency on the WS-Coordination and WS-Transaction specifications. It would be desirable to preserve the content in so far as it provides a succinct model for the semantics of inter scope coordination in BPEL without the dependency on external specifications.
Submitter's proposal: Rewrite appendix C to preserve the relevant content without external dependencies.

 
Resolution: proposed and agreed at f-t-f, 22 Sept 2004

Close with no change to spec.

A sub-group will be formed for interested parties to work on a separate, non-normative document covering the information intended of appendix C. If this group compes up with a document they agree to, they will bring it to the TC for endorsement.
Links: Announcement, 1 Apr 2004     Proposed resolution (Satish Thatte, 4 Jun 2004)     Monica J. Martin, 8 Jun 2004     Diane Jordan, 8 Jun 2004     Monica J. Martin, 8 Jun 2004     Satish Thatte, 8 Jun 2004     Martin Chapman, 8 Jun 2004     Satish Thatte, 8 Jun 2004     Martin Chapman, 8 Jun 2004     Satish Thatte, 8 Jun 2004     Monica J. Martin, 8 Jun 2004     Peter Furniss, 25 Jun 2004     Diane Jordan, 25 Jun 2004     Monica J. Martin, 25 Jun 2004     Peter Furniss, 18 Aug 2004     Peter Furniss, 18 Aug 2004     Satish Thatte, 25 Aug 2004     Peter Furniss, 25 Aug 2004     Francisco Curbera, 14 Sep 2004     Yaron Y. Goland, 16 Sep 2004     Martin Chapman, 16 Sep 2004     Alastair J. Green, 20 Sep 2004     Satish Thatte, 22 Sep 2004     Peter Furniss, 22 Sep 2004     Satish Thatte, 22 Sep 2004     Peter Furniss, 22 Sep 2004     Satish Thatte, 22 Sep 2004     Mark Little, 23 Sep 2004     Mark Little, 23 Sep 2004
Changes: 1 Apr 2004 - new issue;    1 Apr 2004 - fields: Links;    25 Jun 2004 - fields: Links, Status, Proposed resolution;    18 Aug 2004 - fields: Links;    26 Aug 2004 - fields: Links;    14 Sep 2004 - fields: Links;    16 Sep 2004 - fields: Links;    21 Sep 2004 - fields: Links;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution, In spec, Links


Issue 116: <process> element should be optional

Status: resolved
In spec: No change
Date added: 1 Apr 2004
Categories: Syntax and validation
Date submitted: 1 April 2004
Submitter: Peter Furniss
Description: At present, a BPEL script has to have a top-level <process> element as the container for all the interesting activities and stuff. However, although there syntactically needs to a top-level xml element, the idea that this should be a single defined process, with a single purpose, does not reflect common business behaviour.

In older business processes (such as those entirely or predominantly operated by humans) it is very common for fragments of process to survive long after the circumstances that justified those fragments have ceased to be relevant. Long-lived "business" processes, such as procedures and customs of national legislatures are good examples of this.

Although BPEL is concerned with automated processes, it should be possible to re-implement human-implemented processes in BPEL, and similarly we should expect BPEL processes to evolve in a similar way, with relics of former requirements continuing to be defined in the script. Thus it would enhance the wide and long-term usefulness of BPEL if the top-level process element were made optional, allowing a BPEL script to contain a disconnected collection of process fragments.
Submitter's proposal: Allow alternative top-level element instead of <process>. The name <bag> might be appropriate.

It is not proposed, at this stage that a BPEL process or bag should be required to be dynamically self-modifying. Such behaviour is of course common in real processes, and could be considered in future BPEL work.
Resolution: Proposed in Peter Furniss, 15 Oct 2004, decided conf call, 27 October 2004

This issue was raised on 1st April at the end of the Waldorf meeting.

It has been suggested that it should be closed with no change, as the committee has no sense of humour. Discussion disproved this, but the consensus is that BPEL isn't funny.

The issue is closed with no change to the spec. Since it is date-specific, it will be used to light pumpkin candles on Halloween.
Links: Announcement, 1 Apr 2004     Discussed at Walldorf f-t-f (document details)     Proposed resolution (Peter Furniss, 15 Oct 2004)
Changes: 1 Apr 2004 - new issue;    1 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links;    18 Oct 2004 - fields: Links, Status, Proposed resolution;    27 Oct 2004 - fields: Status, Proposed resolution, Resolution, In spec


Issue 117: Link Name Scoping

Status: resolved
In spec: 4 June 2004
Date added: 14 Apr 2004
Categories: State management
Date submitted: 14 April 2004
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: BPEL 1.1 Specification
Description: When a flow activity is nested within another flow activity, two links with the same name can be defined, one for each flow. The current specification is unclear about whether such definition is legal, and if legal, how link names are scoped.

Discussion:

Suppose we have the following process:

<flow name="F1">
  <links>
    <link name="L1"/> <!-- L1 is defined here and ... -->
  </links>
  <sequence name="S1">
    <flow name="F2">
      <links>
        <link name="L1"/> <!-- ... here -->
      </links>
      <sequence name="S2">
          <invoke name="I1" ...>
            <target linkName="L1"/> <!-- Which L1? -->
          </invoke>
          ...

Note that link L1 is defined at two places.
Q1: Is this definition legal?
Q2: If legal, is I1 target of L1 of F2 (F2.L1) or L1 of F1 (F1.L1)?
Submitter's proposal: Allow defining links with the same name. For a referencing activity, the inner-most link for the activity hides all other links with the same name. (In the above example, activity I1 is the target of link F2.L1, not F1.L1.)
Resolution: Proposed in Yuzo Fujishima, 22 Apr 2004, decided at 28 April conf call

As submitter's proposal.
Links: Yuzo Fujishima, 13 Apr 2004     rkhalaf, 13 Apr 2004     Yaron Y. Goland, 13 Apr 2004     Announcement, 14 Apr 2004     Proposed resolution (Yuzo Fujishima, 22 Apr 2004)
Changes: 14 Apr 2004 - new issue;    14 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links, Status, Proposed resolution;    29 Apr 2004 - fields: Status, Proposed resolution, Resolution;    9 Jun 2004 - fields: In spec


Issue 118: When are Correlation Sets Mandatory?

Status: resolved
In spec: no change
Date added: 15 Apr 2004
Categories: Correlation
Date submitted: 15 April 2004
Submitter: Yaron Y. Goland
Document: BPEL Specification
Description: It wasn't until Satish explicitly pointed it out to me that I finally understood that all Picks and Receives MUST have at least one correlation set defined on them with "initiate = 'no'" unless the pick/receive is a start activity. I had always assumed that the system was allowed to implicitly route messages based on URL but that is in fact wrong. All routing criteria MUST be explicit and MUST be specified by a correlation set. This also means that it is always illegal to have a pick or receive which does not have at least one correlation set on it.

Normative Change - The schemas for pick and receive make correlation sets optional. That would appear to be wrong.

Also, I'm unclear about what assumptions we make regarding invoke, specifically, is there a requirement to have a correlation set defined on pattern="in" on an invoke? This is kind of a tricky issue. If a synchronous transport is being used then there may not be any explicit information available to mark the response for correlation purposes. In that case do we allow the correlation set for the response to be left off or do we require programmers to use issue 96 : Engine-managed correlation sets ?

Also note, that the WSDL 1.1 spec quite clearly states that request/responses do not have to be sent over synchronous transports so there may be values we could use for correlation sets. In other words, the situation is inconsistent. In some cases a request/response uses a synchronous transport and in other cases it could be using an asynchronous transport with some message based correlation. Do we want to distinguish these cases or do we want to just say that we presume that any time a request/response pattern is used there is some correlation mechanism implicitly known to the engine and therefore correlation sets are always optional on the incoming message? Reply has the same issue as responses on invokes.
Resolution: Proposed and decided on conf call 7 July 2004

Close with no change to the spec.

The concerns covered under this issue will be dealt with under issue 96 : Engine-managed correlation sets
Links: Announcement, 15 Apr 2004     Ugo Corda, 16 Apr 2004     Danny van der Rijn, 16 Apr 2004     Maciej Szefler, 16 Apr 2004     Yaron Y. Goland, 16 Apr 2004     Yaron Y. Goland, 16 Apr 2004     Ugo Corda, 16 Apr 2004     Danny van der Rijn, 16 Apr 2004     Ugo Corda, 16 Apr 2004     Danny van der Rijn, 16 Apr 2004     Ugo Corda, 16 Apr 2004     Ugo Corda, 17 Apr 2004     Eckenfels. Bernd, 17 Apr 2004     Danny van der Rijn, 19 Apr 2004     Yaron Y. Goland, 19 Apr 2004     Maciej Szefler, 19 Apr 2004     Ugo Corda, 19 Apr 2004     Danny van der Rijn, 19 Apr 2004     Ugo Corda, 19 Apr 2004     Ugo Corda, 19 Apr 2004     Maciej Szefler, 19 Apr 2004     Assaf Arkin, 20 Apr 2004     Assaf Arkin, 20 Apr 2004     Eckenfels. Bernd, 20 Apr 2004     Satish Thatte, 22 Apr 2004     Satish Thatte, 22 Apr 2004     Ugo Corda, 22 Apr 2004     Satish Thatte, 22 Apr 2004     Ugo Corda, 22 Apr 2004     Maciej Szefler, 22 Apr 2004     Satish Thatte, 22 Apr 2004     Ugo Corda, 22 Apr 2004     Yaron Y. Goland, 22 Apr 2004     Ugo Corda, 22 Apr 2004     Yaron Y. Goland, 26 Apr 2004     Proposed resolution (Chris Keller, 23 Jun 2004)
Changes: 15 Apr 2004 - new issue;    16 Apr 2004 - fields: Links;    17 Apr 2004 - fields: Links;    19 Apr 2004 - fields: Links;    20 Apr 2004 - fields: Links;    22 Apr 2004 - fields: Links;    23 Apr 2004 - fields: Links;    27 Apr 2004 - fields: Links;    23 Jun 2004 - fields: Links, Status, Proposed resolution;    7 Jul 2004 - fields: Status, Proposed resolution, Resolution, In spec


Issue 119: Transition Conditions and Invoke Fault Handlers

Status: open
Date added: 19 Apr 2004
Categories: Scopes, State management
Date submitted: 16 April 2004
Submitter: Maciej Szefler
Document: Language Specification
Description: The catch-inside-invoke syntactic "shortcut" described in Section 13.4 is unclear with respect to the manner in which transition conditions should be evaluated in case of a fault.

The text currently provides an example as to how the shortcut should be interpreted, that goes as follows :

<invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <catch faultName="SP:POFault" faultVariable="POFault">
	<!-- handle the fault -->
     </catch>
</invoke>

is equivalent to / can be re-written as:

<scope>
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
    </invoke>
</scope>

This leads to the quesiton of how to "rewrite" an invoke that is also the source of a link:

<invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <source linkName="foo" />
     <catch faultName="SP:POFault" faultVariable="POFault">
	<!-- handle the fault -->
     </catch>
</invoke>

The options are either:

<scope>
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <source linkName="foo" />
    </invoke>
</scope>
or
<scope>
     <source linkName="foo" />
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
    </invoke>
</scope>

The two versions do not have the same semantics (according to issue 27). In the former case the transition condition will be set to false in the event of a fault. In the latter case the transition condition is evaluated (because the fault is caught and the scope "completes"). While the former interpertation is suggested by the example, the latter interpretation is the more consistent with the resolution of issue 27. This question boils down to the nature of implicit scopes, that is: are implicit scopes merely macros for placing a <scope> around an <invoke>, or does an <invoke> essentially "mix-in" scope features (fault handling).
Links: issue 27 : Setting link status in case of transition condition     Announcement, 19 Apr 2004     rkhalaf, 6 Oct 2004     Maciej Szefler, 8 Oct 2004     rkhalaf, 8 Oct 2004     Yaron Y. Goland, 11 Oct 2004     Maciej Szefler, 11 Oct 2004
Changes: 19 Apr 2004 - new issue;    19 Apr 2004 - fields: Links;    7 Oct 2004 - fields: Links;    11 Oct 2004 - fields: Links;    12 Oct 2004 - fields: Links


Issue 120: What are the semantics when an initial <receive> has no correlation set?

Status: open
Date added: 19 Apr 2004
Categories: Correlation
Date submitted: 19 April 2004
Submitter: Danny van der Rijn
Description: when an initial <receive> has no correlation set should the instance be singleton, or be allowed to have multiple instances outstanding in parallel?
Links: Announcement, 19 Apr 2004     Discussed at San Francisco f-t-f     Danny van der Rijn, 29 Jun 2004     Ron Ten-Hove, 12 Aug 2004     Ugo Corda, 12 Aug 2004     Yaron Y. Goland, 13 Aug 2004     Ugo Corda, 13 Aug 2004     Ron Ten-Hove, 13 Aug 2004     Danny van der Rijn, 13 Aug 2004     Ugo Corda, 13 Aug 2004     Ron Ten-Hove, 16 Aug 2004     Ugo Corda, 16 Aug 2004     Yaron Y. Goland, 16 Aug 2004     Ron Ten-Hove, 16 Aug 2004     Ugo Corda, 16 Aug 2004     Ron Ten-Hove, 16 Aug 2004     Ugo Corda, 16 Aug 2004     Ron Ten-Hove, 16 Aug 2004     Ugo Corda, 16 Aug 2004     Ron Ten-Hove, 16 Aug 2004     Satish Thatte, 24 Aug 2004     Ron Ten-Hove, 27 Aug 2004
Changes: 19 Apr 2004 - new issue;    20 Apr 2004 - fields: Links;    22 Jun 2004 - fields: Links;    29 Jun 2004 - fields: Links;    13 Aug 2004 - fields: Links;    14 Aug 2004 - fields: Links;    17 Aug 2004 - fields: Links;    24 Aug 2004 - fields: Links;    27 Aug 2004 - fields: Links

Issue 121: <finally> construct

Status: resolved
In spec: No change
Date added: 20 Apr 2004
Categories: Scopes, Fault handling
Date submitted: 20 April 2004
Submitter: Glenn Mi
Description: Currently there is not a construct allowing developers to define a fragment of BPEL code that needs be executed any time a scope is exited (whether it be a normal exit or due to a fault).
Revisitable: Yes

Closed with no change to spec and to be marked as revisitable in the next version of spec.
Submitter's proposal: Add a finally construct to the <scope> activity.
Credit: the issue and resolution was suggested by Jerry Thomas (CenterStone Software)
Resolution: Proposed in Alex Yiu, 11 Dec 2004, decided Hawthorne face-to-face
Links: Announcement, 20 Apr 2004     Dieter Koenig1, 27 Apr 2004     Edwin Khodabakchian, 27 Apr 2004     Eckenfels. Bernd, 27 Apr 2004     Edwin Khodabakchian, 27 Apr 2004     Satish Thatte, 20 Jun 2004     Glenn Mi, 21 Jun 2004     Alex Yiu, 2 Nov 2004     Proposed resolution (Alex Yiu, 11 Dec 2004)
Changes: 20 Apr 2004 - new issue;    20 Apr 2004 - fields: Links;    27 Apr 2004 - fields: Links;    29 Apr 2004 - fields: Links;    20 Jun 2004 - fields: Links;    22 Jun 2004 - fields: Links;    3 Nov 2004 - fields: Links;    11 Dec 2004 - fields: Links, Status, Proposed resolution;    14 Dec 2004 - fields: Status, Proposed resolution, Resolution, In spec, Revisitable


Issue 122: Clarify wording for Message Exchange Patterns

Status: resolved
In spec: No change
Date added: 20 Apr 2004
Categories: Correlation
Date submitted: 20 April 2004
Submitter: Eckenfels. Bernd
Champion: Bernd Eckenfels
Document: BPEL Spec
Description: The BPEL Specification is talking about a synchronous operation to describe the fact that a two-way Message Exchnage Pattern is used for invoking or providing a service. This is a bit confusing, since synchronous is often used as a property of the binding and the transmission protocol, whereas BPEL only refers to the fact, that there is a pattern correlating a request, with and response and possible some faults.

A possible resolution would be, to remove the term synchronous, while talking about operations, in favor of the term "two way" or request-response or something similiar.

Note: it is not so easy to use the MEP names from WSDL, since they are afaik not defined for wsdl1.1 and they refer to an operation from the provider and consumer side, whereas BPEL only knows the provider side as receive/replay and the consumer side as invoke.
Resolution: Proposed verbally and decided at San Francisco f-t-f

Editors will ensure that "synchronous" and "asynchronous" are not used in the context of invoking or providing a service, and in 11.4 relating to reply. All uses of these words will be reviewed and revised to ensure they are used consistently in any other cases. The term "blocking" will also be avoided.
Links: This issue was discovered in the discussion about issue 118 : When are Correlation Sets Mandatory?     Announcement, 20 Apr 2004
Changes: 20 Apr 2004 - new issue;    20 Apr 2004 - fields: Links;    23 Jun 2004 - fields: In spec, Resolution, Status


Issue 123: Matching <reply> with <receive>

Status: resolved
In spec: 21 Oct 2004
Date added: 18 May 2004
Categories: Correlation
Date submitted: 18 May 2004
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: WSBPEL Working Draft, April 23, 2004
Description:

The rule of matching a reply activity with a receive activity is not clearly defined in the current specification.

Discussion:

The current specification is not defined clearly enough to answer the following questions.

[Q1] Must <reply> always specify all the correlation sets specified by the corresponding <receive>?

For example, if there are two <receive>'s outstanding as follows,

    receive name="rec1" partnerLink="pl" portType="pt" operation="op"
      correlation set="cs1" initiate="no"
      correlation set="cs2" initiate="no"
      correlation set="cs3" initiate="yes"
      correlation set="cs4" initiate="yes"

receive name="rec2" partnerLink="pl" portType="pt" operation="op" correlation set="cs1" initiate="no" correlation set="cs2" initiate="no" correlation set="cs5" initiate="yes" correlation set="cs6" initiate="yes"

Must a <reply> specify all of the corresponding <receive>'s CS's? That is, for rec1,

    reply name="rep1" partnerLink="pl" portType="pt" operation="op"
      correlation set="cs1" initiate="no"
      correlation set="cs2" initiate="no"
      correlation set="cs3" initiate="no"
      correlation set="cs4" initiate="no"

Or only as many as necessary to disambiguate the matching?

    reply name="rep1" partnerLink="pl" portType="pt" operation="op"
      correlation set="cs3" initiate="no"

[Q2] Does it follow that if a <receive> specify a correlation set, the corresponding reply can only send a message that contains the correlation set?

If it does, then the rule seems to be too restrictive. For example, the following process will be illegal.

  1. receive a Purchase Order and initialize correlation set CS-PO.
  2. synchronously reply with an acknowledge message not containing CS-PO. <- Illegal
  3. receive and/or invoke using CS-PO to perform the rest of the PO process.

Resolution: Proposed in Alex Yiu, 1 Sep 2004, decided on conf call, 29 Sept 2004

A reply activity is associated with a receive activity based on the tuple - partnerLink, operation, and messageExchange. The value defined in messageExchange is scoped to the combination of partnerLink and operation. That is, it is legal to use the same messageExchange value in multiple simultaneously incomplete receive activities so long as the combination of partnerLink and operation on the receives are all different from each other. An incomplete receive describes the state of a BPEL process from the point that a request/response receive activity starts execution until its associated reply begins execution.

If there should ever be multiple simultaneous incomplete receive activities which have the same partnerLink, operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown within the BPEL process on the conflicting receive activities subsequent to the execution of the successful incomplete receive.

If a reply activity cannot be associated with an incomplete receive activity by matching the tuples and this error situation is not caught during static analysis, then bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests should have been rejected at the time <receive> is executed, there cannot be more than one corresponding <receive> at the time <reply> is executed.

If the messageExchange attribute is not specified on a receive then its value is taken to be empty. For matching purposes two empty messageExchange values on receives with the same partnerLink and operation values are said to match. Empty value does not match with other non-empty values.

(Please note: there are existing text paragraphs in the spec, which enforces that no more than one <receive>s are waiting for a message associated with the same partner link, port type, operation, and correlation sets. This constraint still exists and will not be affected by the proposal of Issue 123. This proposal simply add one more constraint to receive, when <reply> are needed to be associated with <receive>.)
Links: Yuzo Fujishima, 13 May 2004     Satish Thatte, 13 May 2004     Ugo Corda, 13 May 2004     Eckenfels. Bernd, 17 May 2004     Satish Thatte, 17 May 2004     Announcement, 18 May 2004     Eckenfels. Bernd, 18 May 2004     Francisco Curbera, 4 Jun 2004     Yuzo Fujishima, 7 Jun 2004     Yaron Y. Goland, 7 Jun 2004     Francisco Curbera, 7 Jun 2004     John Evdemon, 16 Jun 2004     20040622-issue123.ppt (document details)     Discussed at San Francisco f-t-f     expected to deal with issue 26     issue 96 : Engine-managed correlation sets     Yuzo Fujishima, 30 Jun 2004     Assaf Arkin, 1 Jul 2004     Danny van der Rijn, 1 Jul 2004     Danny van der Rijn, 1 Jul 2004     Assaf Arkin, 1 Jul 2004     Danny van der Rijn, 1 Jul 2004     Yuzo Fujishima, 2 Jul 2004     Yuzo Fujishima, 2 Jul 2004     Yaron Y. Goland, 2 Jul 2004     Assaf Arkin, 2 Jul 2004     Prasad Yendluri, 2 Jul 2004     Yuzo Fujishima, 5 Jul 2004     Yuzo Fujishima, 5 Jul 2004     Eckenfels. Bernd, 6 Jul 2004     Eckenfels. Bernd, 6 Jul 2004     Yaron Y. Goland, 6 Jul 2004     Ugo Corda, 6 Jul 2004     Satish Thatte, 7 Jul 2004     Satish Thatte, 7 Jul 2004     Francisco Curbera, 7 Jul 2004     Assaf Arkin, 7 Jul 2004     Satish Thatte, 7 Jul 2004     Satish Thatte, 7 Jul 2004     Yaron Y. Goland, 7 Jul 2004     Satish Thatte, 7 Jul 2004     Yuzo Fujishima, 9 Jul 2004     Satish Thatte, 12 Jul 2004     Yaron Y. Goland, 12 Jul 2004     Satish Thatte, 12 Jul 2004     Yaron Y. Goland, 12 Jul 2004     Eckenfels. Bernd, 12 Jul 2004     Satish Thatte, 12 Jul 2004     Yaron Y. Goland, 13 Jul 2004     Francisco Curbera, 20 Jul 2004     Yuzo Fujishima, 21 Jul 2004     Eckenfels. Bernd, 21 Jul 2004     Satish Thatte, 21 Jul 2004     Francisco Curbera, 22 Jul 2004     Yaron Y. Goland, 22 Jul 2004     Eckenfels. Bernd, 23 Jul 2004     Francisco Curbera, 23 Jul 2004     Satish Thatte, 29 Jul 2004     Francisco Curbera, 29 Jul 2004     Satish Thatte, 29 Jul 2004     Francisco Curbera, 29 Jul 2004     Satish Thatte, 29 Jul 2004     Francisco Curbera, 29 Jul 2004     Yaron Y. Goland, 30 Jul 2004     Satish Thatte, 30 Jul 2004     Frank Leymann, 31 Jul 2004     Diane Jordan, 2 Aug 2004     Yaron Y. Goland, 3 Aug 2004     Alex Yiu, 4 Aug 2004     Eckenfels. Bernd, 4 Aug 2004     Francisco Curbera, 4 Aug 2004     Alex Yiu, 5 Aug 2004     Alex Yiu, 5 Aug 2004     Maciej Szefler, 5 Aug 2004     Francisco Curbera, 5 Aug 2004     Alex Yiu, 5 Aug 2004     Alex Yiu, 5 Aug 2004     Yaron Y. Goland, 6 Aug 2004     Yaron Y. Goland, 6 Aug 2004     Alex Yiu, 6 Aug 2004     Alex Yiu, 6 Aug 2004     Satish Thatte, 9 Aug 2004     Yaron Y. Goland, 9 Aug 2004     Yaron Y. Goland, 9 Aug 2004     Alex Yiu, 9 Aug 2004     Satish Thatte, 9 Aug 2004     Alex Yiu, 9 Aug 2004     Yaron Y. Goland, 11 Aug 2004     Yaron Y. Goland, 11 Aug 2004     Alex Yiu, 11 Aug 2004     Satish Thatte, 13 Aug 2004     Alex Yiu, 13 Aug 2004     Satish Thatte, 13 Aug 2004     Alex Yiu, 18 Aug 2004     Yuzo Fujishima, 18 Aug 2004     Yaron Y. Goland, 18 Aug 2004     Alex Yiu, 18 Aug 2004     Danny van der Rijn, 18 Aug 2004     Alex Yiu, 1 Sep 2004     Yuzo Fujishima, 1 Sep 2004     Danny van der Rijn, 1 Sep 2004     Alex Yiu, 1 Sep 2004     Proposed resolution (Alex Yiu, 1 Sep 2004)     Danny van der Rijn, 1 Sep 2004     Alex Yiu, 1 Sep 2004     Proposed resolution (Alex Yiu, 1 Sep 2004)     Proposed resolution (Yaron Y. Goland, 10 Sep 2004)     Francisco Curbera, 14 Sep 2004
Changes: 18 May 2004 - new issue;    18 May 2004 - fields: Links;    9 Jun 2004 - fields: Links;    16 Jun 2004 - fields: Links;    22 Jun 2004 - fields: Links;    30 Jun 2004 - fields: Links;    2 Jul 2004 - fields: Links;    3 Jul 2004 - fields: Links;    5 Jul 2004 - fields: Links;    6 Jul 2004 - fields: Links;    7 Jul 2004 - fields: Links;    13 Jul 2004 - fields: Links;    14 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    22 Jul 2004 - fields: Links;    23 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links;    31 Jul 2004 - fields: Links;    1 Aug 2004 - fields: Links;    2 Aug 2004 - fields: Links;    4 Aug 2004 - fields: Links;    5 Aug 2004 - fields: Links;    6 Aug 2004 - fields: Links;    7 Aug 2004 - fields: Links;    9 Aug 2004 - fields: Links;    10 Aug 2004 - fields: Links;    12 Aug 2004 - fields: Links;    14 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Links;    1 Sep 2004 - fields: Links;    2 Sep 2004 - fields: Links, Status, Proposed resolution;    10 Sep 2004 - fields: Links, Status, Proposed resolution;    13 Sep 2004 - fields: Proposed resolution;    15 Sep 2004 - fields: Links;    29 Sep 2004 - fields: Status, Proposed resolution, Resolution;    23 Oct 2004 - fields: In spec


Issue 124: PartnerLink/URI setter/getter function

Status: resolved
In spec: no change
Date added: 18 May 2004
Categories: Partner links
Date submitted: 18 May 2004
Submitter: Yaron Y. Goland
Description: The most common operation one can expect on a partnerLink is to retrieve or set its URI. Today there is no well defined way to perform either action in BPEL.
Revisitable: Yes
Submitter's proposal: Introduce a dedicated activity to allow one to retrieve the URI of a partnerLink and/or set the URI of a partnerLink. In the case of setting the URI if the submitted URI is not acceptable then a fault will be thrown.
Proposed resolution: Yaron Y. Goland, 23 Dec 2004
Links: Yaron Y. Goland, 14 May 2004     Announcement, 18 May 2004     Proposed resolution (Yaron Y. Goland, 23 Dec 2004)
Changes: 18 May 2004 - new issue;    18 May 2004 - fields: Links;    23 Dec 2004 - fields: Links, Status, Proposed resolution;    28 Dec 2004 - fields: Links, Status, Proposed resolution

Issue 125: Literal and Expression Assignment Semantics

Status: resolution proposed
Date added: 25 May 2004
Categories: Expressions, Syntax and validation
Date submitted: 25 May 2004
Submitter: Yuzo Fujishima
Document: WSBPEL Working Draft, April 23, 2004
Description: The assignment semantics for literal and expression values needs clarification. The current specification seems to be unable to clearly answer to the questions asked in Yuzo Fujishima, 18 May 2004
Champions: Yuzo Fujishima <fujishima@bc.jp.nec.com>
Proposed resolution: Yuzo Fujishima, 6 Dec 2004 andrew.francis, 6 Dec 2004 Yaron Y. Goland, 6 Dec 2004 Yuzo Fujishima, 7 Dec 2004 Yuzo Fujishima, 7 Dec 2004
Links: Yuzo Fujishima, 18 May 2004     Ugo Corda, 18 May 2004     Announcement, 25 May 2004     20040622-issue125.ppt (document details)     Proposed resolution (Yuzo Fujishima, 6 Dec 2004)     andrew.francis, 6 Dec 2004     Yaron Y. Goland, 6 Dec 2004     Yuzo Fujishima, 7 Dec 2004     Yuzo Fujishima, 7 Dec 2004
Changes: 25 May 2004 - new issue;    25 May 2004 - fields: Links;    21 Jun 2004 - fields: Links;    7 Dec 2004 - fields: Links, Status, Proposed resolution;    8 Dec 2004 - fields: Links

Issue 126: Event Handlers with local partnerLinks & Correlation Sets

Status: resolution proposed
Date added: 10 Jun 2004
Categories: Correlation, Partner links, Event handling
Date submitted: 04 June 2004
Submitter: Yaron Y. Goland
Description: This issue has two closely related parts. For each part, an example and a problem description are given. The submitter's proposal is also in two parts.

Part A

Example: A factory consists of manufacturing machines and a system of heat monitors. A BPEL process receives updates from the heat monitors and uses the updates to configure the manufacturing machines so they operate at their ideal temperature. The BPEL process does not know at deployment time what heat monitors are available and the number of available monitors is constantly changed anyway as new ones are added, old ones are replaced, etc. Additionally since the updates can indicate emergency situations its important that the updates be accepted asynchronously and on-demand so that emergency action can be taken if necessary. Therefore an event handler is used to deal with these messages.

Problem Description: The BPEL process wants to create an event handler which can accept incoming heat status updates. All heat status messages are received on the same operation on the same portType. The BPEL code looks like:

process
    partnerLinks
       partnerLink name="monitor" ...
    scope
       eventHandlers
          onEvent partnerLink="monitor" portType="tempEvents"
                  operation="tempUpdate" ...
             ...
       ...
Time 0 - Scope is entered and onEvent is activated

Time 1 - Monitor A sends a "tempUpdate" message that is caught by the onEvent handler. partnerLink monitor is initialized to point at Monitor A.

Time 2 - Monitor B sends a "tempUpdate" message but the message is thrown on the floor because partnerLink monitor is already initialized to point to monitor A.

Part B

Example: A BPEL process places an order for a set of items with a known partner. The BPEL process then expects to receive asynchronous notifications of the status of the shipment. Each notification will contain the orderID used on the initial order. However it is possible for a single order to be broken up into multiple shipments. Therefore each update message contains a shippingID. Upon receiving a shipping update the BPEL process is expected to send back a response confirming receipt of the update that contains both the orderID and the shippingID.

Problem Description:

process
    partnerLinks
       partnerLink name="partner" ...
    correlationSets
       correlationSet name="orderID"
    scope
       <!-- Init partnerLink & orderID, place order -->
       ...
       scope
          correlationSets
             correlationSet name="shippingID"
          onEvent partnerLink="partner" ...
             correlations
                correlation set="orderID" initiate="no"
                correlation set="shippingID" initiate="yes"
             scope
                ...
                reply partnerLink="partner" ...
                   correlation set="orderID" initiate="no"
                   correlation set="shippingID" initiate="no"
          ...
       ...

Time 0 - The parent scope is entered, the partnerLink pointing at the partner is initialized and the order is placed.

Time 1 - The inner scope is entered, the onEvent handler becomes active and waits for a message from the partner.

Time 2 - The first status message arrives and initiates the shippingID. A response is sent to the partner indicating receipt of the status message.

Time 3 - The second status message arrives. But it turns out that the order has been split and so this second status message has a different shippingID then the first status message. Since the shippingID has already been initialized to a different value the second status message is dropped on the floor.

Note, btw, that strictly speaking all messages after the first one no matter what correlation set they had would have been rejected because initiate="yes" would cause an error after the first message. While this may appear to argue for initiate="maybe" this fault isn't actually relevant to this issue.
Submitter's proposal:

Part A

The partnerLink attribute on the onEvent element be made optional and a partnerLink element be added as an optional child of the onEvent element. The optional partnerLink element would be used to declare a partnerLink that was local to each instance of the onEvent handler. It would be mandatory that all onEvent handlers either use the partnerLink attribute or the partnerLink element but not both.

In other words:

process
    scope
       eventHandlers
          onEvent portType="tempEvents" operation="tempUpdate" ...
             partnerLink name="monitor" ...
             ...
       ...

Part B

Add the correlationSet element as an optional child of the onEvent element. Any correlation set values defined on the onEvent element are only available within the scope of the onEvent.

process
    partnerLinks
       partnerLink name="partner" ...
    correlationSets
       correlationSet name="orderID"
    scope
       <!-- Init partnerLink & orderID, place order -->
       ...
       scope
          onEvent partnerLink="partner" ...
             correlationSets
                correlationSet name="shippingID"
             correlations
                correlation set="orderID" initiate="no"
                correlation set="shippingID" initiate="yes"
             scope
                ...
                reply partnerLink="partner" ...
                   correlation set="orderID" initiate="no"
                   correlation set="shippingID" initiate="no"
          ...
       ...

Proposed resolution: Yaron Y. Goland, 30 Jun 2004 Discussed but not agreed on conf call 7 July 2004

Accept the submitter's proposal above.
Links: Announcement, 10 Jun 2004     Ugo Corda, 11 Jun 2004     Satish Thatte, 12 Jun 2004     Frank Leymann, 13 Jun 2004     Yaron Y. Goland, 14 Jun 2004     Yaron Y. Goland, 14 Jun 2004     Satish Thatte, 14 Jun 2004     Ugo Corda, 14 Jun 2004     Prasad Yendluri, 15 Jun 2004     Yaron Y. Goland, 15 Jun 2004     Prasad Yendluri, 15 Jun 2004     Yaron Y. Goland, 16 Jun 2004     Prasad Yendluri, 16 Jun 2004     Yaron Y. Goland, 16 Jun 2004     Prasad Yendluri, 16 Jun 2004     Assaf Arkin, 16 Jun 2004     Prasad Yendluri, 16 Jun 2004     Dieter Koenig1, 17 Jun 2004     Yaron Y. Goland, 17 Jun 2004     Prasad Yendluri, 17 Jun 2004     Assaf Arkin, 18 Jun 2004     Yaron Y. Goland, 18 Jun 2004     Prasad Yendluri, 18 Jun 2004     Francisco Curbera, 23 Jun 2004     Yaron Goland, 30 Jun 2004     Proposed resolution (Yaron Y. Goland, 30 Jun 2004)     Prasad Yendluri, 2 Jul 2004     Yaron Y. Goland, 6 Jul 2004
Changes: 10 Jun 2004 - new issue;    10 Jun 2004 - fields: Links;    11 Jun 2004 - fields: Links;    13 Jun 2004 - fields: Links;    15 Jun 2004 - fields: Links;    16 Jun 2004 - fields: Links;    17 Jun 2004 - fields: Links;    18 Jun 2004 - fields: Links;    19 Jun 2004 - fields: Links;    23 Jun 2004 - fields: Links;    30 Jun 2004 - fields: Links;    1 Jul 2004 - fields: Links, Status, Proposed resolution;    3 Jul 2004 - fields: Links;    6 Jul 2004 - fields: Links;    7 Jul 2004 - fields: Status, Proposed resolution, Resolution;    15 Jul 2004 - fields: Status, Resolution, Proposed resolution


Issue 127: Locally Scoped Partners

Status: resolved
In spec: no change
Date added: 11 Jun 2004
Categories: Partner links
Date submitted: 11 June 2004
Submitter: Dieter Koenig1
Document: BPEL4WS 1.1 (May 5, 2003), Section 7.3 "Business Partners", and resolved issue 75 : Locally Scoped partnerLink declarations .
Description: In Section 7.3, the partner element is defined as a subelement of the process, and described as "as a subset of the partner links of the process". With the resolution of issue 75, a BPEL partnerLink can now be declared on a scope. It is no longer sufficient to have one global partner element that refers to partnerLinks by ncname. One could think of several alternatives to deal with this situation:
  1. partner elements defined locally to scopes
  2. partner elements for the process can only refer to partnerLinks defined in the process (not desirable as other partnerLinks are ignored)
  3. partner elements for the process can refer to all partnerLinks (not desirable as this violates visibility rules)

Submitter's proposal: We propose that the partner element can be defined as subelement of a scope.
Resolution: During the TC teleconference meeting held 5 January 2005 the TC resolved issue 130 on partner element by deciding not to include it (i.e. no change will be made to the specification). Given that resolution of issue 130, this issue 127 became no longer meaningful. The TC therefore agreed to close this issue with no change to the specification.


Links: Announcement, 11 Jun 2004
Changes: 11 Jun 2004 - new issue;    12 Jun 2004 - fields: Links


Issue 128: WS-I BP Incompatible WSDL Import

Status: resolved
In spec: 16 Aug 2004
Date added: 14 Jun 2004
Categories: Related standards
Date submitted: 14 June 2004
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: WSBPEL Working Draft, April 23, 2004
Description: The example WSDL in 6.1 imports an XML Schema Definition file in a way incompatible with WS-I Basic Profile.

The example imports the XSD file as:

<definitions ...
  <import namespace="http://manufacturing.org/xsd/purchase"
        location="http://manufacturing.org/xsd/purchase.xsd"/>

where this kind of import is prohibited in WS-I BP section 5.1.2:
R2001: A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description.
R2002: To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement.
R2003: A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section.
Submitter's proposal: Modify the example as follows:

<definitions ...
  <types>
    <xsd:schema>
      <xsd:import namespace="http://manufacturing.org/xsd/purchase"
         location="http://manufacturing.org/xsd/purchase.xsd"/>

Resolution: Proposed in Yuzo Fujishima, 15 Jun 2004, decided at San Francisco f-t-f

Apply the submitter's proposal

Kevin Liu will review the spec for examples that need similar correction and bring them to the spec editing team and the TC.

The spec editing team will check the wording arising from issue 72 : What to do with WS-I BP1.0? to ensure it is strong enough.
Links: Announcement, 14 Jun 2004     Ugo Corda, 14 Jun 2004     Proposal to vote (Yuzo Fujishima, 15 Jun 2004)     20040622-issue128.ppt (document details)
Changes: 14 Jun 2004 - new issue;    14 Jun 2004 - fields: Links;    15 Jun 2004 - fields: Status, Proposed resolution, Links;    23 Jun 2004 - fields: Status, Proposed resolution, Resolution;    17 Aug 2004 - fields: In spec


Issue 129: Inconsistent Name Attribute Usage in PartnerLinkType

Status: resolved
In spec: 16 Nov 2004
Date added: 14 Jun 2004
Categories: Syntax and validation
Date submitted: 14 June 2004
Submitter: Yuzo Fujishima
Champion: Yuzo Fujishima
Document: WSBPEL Working Draft, April 23, 2004
Description: Currently, the "name" atttribute of a "portType" element is used within a "role" element within a "partnerLinkType" element to specify a port type associated with the role.

All other "name" attributes in the WSBPEL specificaiton are used to define the name of the object defined there, not the object referenced. Accordingly, all other "name"s are NCName where only the above portType name is QName.

<plnk:partnerLinkType name="ncname">
  <plnk:role name="ncname">+
    <plnk:portType name="qname"/>
  </plnk:role>
</plnk:partnerLinkType>

Submitter's proposal: Replace "portType" element with the newly introduced "responsibility" element that has "portType" attribute.
<plnk:partnerLinkType name="ncname">
  <plnk:role name="ncname">+
    <plnk:responsibility portType="qname"/>
  </plnk:role>
</plnk:partnerLinkType>

Resolution: proposed in Chris Keller, 21 Sep 2004, agreed at f-t-f, 22 Sept 2004

Replace the portType element of the partnerLinkType role definition with a portType attribute as the role is one-to-one with portType. New abbreviated partnerLinkType syntax would be:

 
	<plnk:partnerLinkType name="ncname">
         <plnk:role name="ncname" portType="qname"/>+
	</plnk:partnerLinkType> 

Links: Announcement, 14 Jun 2004     Proposed resolution (Yuzo Fujishima, 8 Sep 2004)     Discussed at conf call, 15 Sept 2004     Proposed resolution (Chris Keller, 21 Sep 2004)
Changes: 14 Jun 2004 - new issue;    15 Jun 2004 - fields: Links;    8 Sep 2004 - fields: Links, Status, Proposed resolution;    15 Sep 2004 - fields: Links;    21 Sep 2004 - fields: Links, Status, Proposed resolution;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution;    17 Nov 2004 - fields: In spec

Issue 130: Remove Partner Element

Status: resolved
In spec: no change
Date added: 6 Jul 2004
Categories: Syntax and validation, Partner links
Date submitted: 06 July 2004
Submitter: Yaron Y. Goland
Description: The partner element seems more of an experiment than a fully mature feature and so it is recommended that it be removed from BPEL.
Proposed resolution: Yaron Y. Goland, 20 Dec 2004 Danny van der Rijn, 20 Dec 2004 Francisco Curbera, 21 Dec 2004 Prasad Yendluri, 21 Dec 2004
Links: Alex Yiu, 29 Jun 2004     Alex Yiu, 29 Jun 2004     Frank.Leymann@t-online.de, 29 Jun 2004     Ron Ten-Hove, 29 Jun 2004     Francisco Curbera, 30 Jun 2004     Yaron Y. Goland, 2 Jul 2004     Eckenfels. Bernd, 2 Jul 2004     Alex Yiu, 2 Jul 2004     Prasad Yendluri, 2 Jul 2004     Yaron Y. Goland, 6 Jul 2004     Announcement, 6 Jul 2004     Proposed resolution (Yaron Y. Goland, 22 Jul 2004)     Prasad Yendluri, 22 Jul 2004     Yaron Y. Goland, 23 Jul 2004     Proposed resolution (Yaron Y. Goland, 20 Dec 2004)     Danny van der Rijn, 20 Dec 2004     Francisco Curbera, 21 Dec 2004     Prasad Yendluri, 21 Dec 2004     Eckenfels. Bernd, 29 Dec 2004     Satish Thatte, 4 Jan 2005     Maciej Szefler, 5 Jan 2005
Changes: 6 Jul 2004 - new issue;    6 Jul 2004 - fields: Links;    7 Jul 2004 - fields: Links;    22 Jul 2004 - fields: Links, Status, Proposed resolution;    23 Jul 2004 - fields: Links, Status, Proposed resolution;    21 Dec 2004 - fields: Links, Status, Proposed resolution;    23 Dec 2004 - fields: Links;    30 Dec 2004 - fields: Links;    3 Jan 2005 - fields: Links;    5 Jan 2005 - fields: Links;    6 Jan 2005 - fields: Links

Issue 131: revisiting section 9.3.1 "Type Compatibility in Assignment"

Status: resolved
In spec: No change
Date added: 13 Jul 2004
Categories: Data handling, Expressions
Date submitted: 12 July 2004
Submitter: Alex Yiu
Description:

Some of the constraints imposed by Section 9.3.1 "Type Compatibility in Assignment" in the current version of the specification (as of July 12, 2004) are not so reasonable.

For example, it said:

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

If my reading is right, it outlaws a simple copy of a element or a text-node from a part of a WSDL message to a element-based or a simple-type-based variable and vice versa. This usage pattern is clearly needed.

Other considerations suggested by other TC members includes: simple type conversion: e.g. a string type => a boolean type conversion.

We need to re-visit that section of the specification and come up with a more reasonable of type compatiblity constraints.
Resolution: Closed as a duplicate of issue 51 : Section 9.3.1 & Schema Validation
Links: Announcement, 13 Jul 2004     Yaron Y. Goland, 13 Jul 2004     Alex Yiu, 13 Jul 2004     Peter Furniss, 13 Jul 2004
Changes: 13 Jul 2004 - new issue;    13 Jul 2004 - fields: Links;    14 Jul 2004 - fields: Links, Status, In spec, Resolution;    16 Jul 2004 - fields: Links


Issue 132: In-line Variable Initialization

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: In most programming languages it is possible to initialize the value of a variable when it is declared. This is not just a space saving mechanism but is a way of binding together the variable with its initialization so as to ensure that nothing is accidentally inserted between when a variable is declared and when it is initialized.
Submitter's proposal: We should introduce syntax to allow for all BPEL variables to be initialized inline with their declaration.
Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 133: Access to unnamed fault bodies

Status: open
Date added: 15 Jul 2004
Categories: Fault handling
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: If a fault is caught using a catch all then how does one gain access to the name and value of the thrown fault? If a fault is caught using a type catch with no name how does one gain access to the name? If only for logging purposes.
Submitter's proposal: We can define a variable on both catch all and type catch of type xs:any. In both cases the content of the variable would be a single element with the name of the fault. In the case of catch all the contents of that element would be the fault body. In the case of a 'type catch' it would be empty.
Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 134: Non-Integer XPATHS

Status: resolved
In spec: 21 Oct 2004
Date added: 15 Jul 2004
Categories: Expressions
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Section 9.1.4 forbids XPATHs that use non-integer arithmetic. This is a violation of the XPATH standard which explicitly provides for full floating point based arithmetic.
Submitter's proposal: Remove the restrictions on integer only math and the related restrictions this spawned on things like division and equality operators.
Resolution: proposed in Yaron Y. Goland, 16 Sep 2004, agreed at f-t-f, 22 Sept 2004

Remove all but the first paragraph of section 9.1.4.

Raise a new issue (issue 163 : languageExecutionFault ) to cover language problems.
Links: Announcement, 15 Jul 2004     Yaron Y. Goland, 27 Aug 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    27 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution;    23 Oct 2004 - fields: In spec


Issue 135: Clarifying forcedTermination Handler

Status: resolved
In spec: 19 Nov 2004
Date added: 15 Jul 2004
Categories: Syntax and validation, State management
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: The name 'forcedTermination' is really confusing to me because the forcedTermination handler is not called when the terminate activity is called. This makes sense since terminate means 'die NOW' not 'first run a bunch of clean up and then die' but the name caused me a lot of confusion.

The semantics of the forcedTermination handler, that it can't throw any faults, makes sense but I think the way we specify fault handlers could cause programmers some serious headaches. For example, if someone defines a catchAll handler and they don't define a forcedTermination handler then if a scope is killed the catchAll handler will catch the forcedTermination fault. However the catchAll handler's logic probably thinks it can throw its own faults, which will normally be true unless the fault it caught was a forcedTermination fault. Yuck.
Submitter's proposal: Change the name to something like faultCleanUpHandler.

We should probably define an implicit forcedTermination handler on all scopes. If someone doesn't define an explicit forcedTermination handler then the implicit one (which will do nothing) will run. This means that catchAll will never catch a forcedTermination fault.
Resolution: Proposed in Satish Thatte, 24 Sep 2004, decided 13 Oct 2004 conf call

Overview:

The bpws:forcedTermination "fault" in the current specification is not a normal fault. It is simply a way to permit interception of forced termination by a scope to perform special handling to shut the scope down in an orderly manner. The differences from a normal fault include the inability to be caught by a catchAll handler, and the inability to throw or rethrow any fault within the handler. It is thus proposed that we eliminate the notion of a bpws:forcedTermination fault from the specification and replace it with a notion of a special handler for forced termination. A secondary part of the proposal is to replace the <terminate/> activity with an <exit/> activity with identical semantics, simply to avoid terminological confusion with the notion of forced termination.

Detailed proposal:

In all the text of the specification, including section 5 and Appendix A, eliminate the mention of bpws:forcedTermination and remove this token from the bpws namespace.

In Sections 6.2 and 13

Replace the syntax

 <scope variableAccessSerializable="yes|no" standard-attributes>
        standard-elements
        <variables>?
            ...
        </variables>
        <correlationSets>?
            ...
        </correlationSets>
        <faultHandlers>?
            ...
        </faultHandlers>
        <compensationHandler>?
            ...
        </compensationHandler>
        <eventHandlers>?
            ...
        </eventHandlers>
        activity
</scope>

with the syntax

<scope variableAccessSerializable="yes|no" standard-attributes>
        standard-elements
        <variables>?
            ...
        </variables>
        <correlationSets>?
            ...
        </correlationSets>
        <faultHandlers>?
            ...
        </faultHandlers>
        <compensationHandler>?
            ...
        </compensationHandler>
        <terminationHandler>?
            ...
        </terminationHandler>
        <eventHandlers>?
            ...
        </eventHandlers>
        activity
</scope>

In Section 13.4.2

Replace the text

Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the behavior of the scope is interrupted and the fault handler for the standard bpws:forcedTermination fault is run. Note that this applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then as stated above, all other fault handlers including the handler for bpws:forcedTermination are uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete.

The fault handler for the bpws:forcedTermination fault is designed like other fault handlers, but this fault handler cannot rethrow any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already faulted, which is what is causing the forced termination of the nested scope.

In other respects this is a normal fault handler. Its behavior begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active. It can invoke compensate activities. And when it is missing, it is provided by using the same implicit behavior that is used for all other implicit fault handlers.

Note that forced termination of nested scopes occurs in innermost-first order as a result of the rule (quoted above) that the behavior of any fault handler begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active.

with the text

Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the forced termination of a scope begins by terminating all activities directly enclosed within its associated scope that are currently active. Following this, the custom termination handler for the scope, if present, is run. If the custom termination handler is missing, the default termination handler performs compensation of all successfully completed nested scopes in the same order as in the case of a default fault handler.

Forced termination for a scope applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then the termination handler is uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete.

The termination handler for a scope is permitted to use the same range of activities as a fault handler, including the <compensate/> activity. However, a termination handler cannot throw any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already either faulted or is in the process of being terminated, which is what is causing the forced termination of the nested scope.

Forced termination of nested scopes occurs in innermost-first order as a result of the rule (stated above) that the termination handler is run after terminating all activities (including scope activities) directly enclosed within its associated scope that are currently active.


Links: Announcement, 15 Jul 2004     Yaron Y. Goland, 12 Aug 2004     Alex Yiu, 17 Aug 2004     Yaron Y. Goland, 18 Aug 2004     Alex Yiu, 3 Sep 2004     Satish Thatte, 3 Sep 2004     Frank Leymann, 3 Sep 2004     Alex Yiu, 3 Sep 2004     Satish Thatte, 3 Sep 2004     Yaron Y. Goland, 10 Sep 2004     Alex Yiu, 13 Sep 2004     Yaron Y. Goland, 13 Sep 2004     Alex Yiu, 14 Sep 2004     Proposed resolution (Satish Thatte, 24 Sep 2004)     Danny van der Rijn, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Danny van der Rijn, 24 Sep 2004     Satish Thatte, 24 Sep 2004     Alex Yiu, 27 Sep 2004     Satish Thatte, 27 Sep 2004     Alex Yiu, 28 Sep 2004     Assaf Arkin, 28 Sep 2004     Satish Thatte, 28 Sep 2004     Satish Thatte, 28 Sep 2004     Alex Yiu, 28 Sep 2004     Alex Yiu, 28 Sep 2004     Assaf Arkin, 28 Sep 2004     Satish Thatte, 29 Sep 2004     Satish Thatte, 29 Sep 2004     Assaf Arkin, 30 Sep 2004     Assaf Arkin, 30 Sep 2004     Satish Thatte, 30 Sep 2004     Satish Thatte, 30 Sep 2004     Alex Yiu, 1 Oct 2004     Assaf Arkin, 5 Oct 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    13 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Links;    3 Sep 2004 - fields: Links;    10 Sep 2004 - fields: Links;    13 Sep 2004 - fields: Links;    14 Sep 2004 - fields: Links;    20 Sep 2004 - fields: Categories;    24 Sep 2004 - fields: Links, Status, Proposed resolution;    25 Sep 2004 - fields: Links;    28 Sep 2004 - fields: Links;    30 Sep 2004 - fields: Links;    4 Oct 2004 - fields: Links;    6 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, Proposed resolution, Resolution;    19 Nov 2004 - fields: In spec

Issue 136: If-Then-Else Activity

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Add support for if-then-else as a complement to switch.
Submitter's proposal:
 <if standard-attributes>
    standard-elements
    <condition expression-language="URI">
       bool-expr
    </condition>
    <then>
       activity
    </then>
    <else>?
       activity
    </else>
</if>
This would effectively be a macro for:
<switch>
    <case>
       <condition>bool-expr</condition>
       activity
    </case>
    <otherwise>
       activity
    </otherwise>
</switch>

Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 137: Making properties consistent with variable values

Status: resolved
In spec: 25 Nov 04
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Currently a property's value is set when a variable is initially set. If the variable's value is subsequently changed then the property's value is not updated. Instead, once the property has been initially set, the state of the property and the state of the underlying variable are no longer correlated. Allowing for a disconnect between the property and its variable is all but guaranteed to lead to misunderstandings.

Imagine a variable that contains a purchase order and the NumOrder property which contains a count of how many orders are in the PO. Now imagine that after the variable is set and the property initialized then the variable is edited to change one PO into two. Now the NumOrder property, still set to the value 1, will no longer have the correct count of orders in the variable.
Submitter's proposal: 1) We should require that any time a variable's value is updated (e.g. with assign) that the property alias for all the properties on the variable should be re-run so the property values will be updated.

2) We should either ban assigning directly to properties or we should specify that properties that are not LValues (e.g. resolve to a single node in the underlying variable) are read-only and properties that are LValues can be written to but the consequence of doing so is that the node in the underlying variable is changed.
Resolution: proposed and agreed at f-t-f, 22 Sept 2004

Closed as an editing change, spec. editing team to work on final wording
Links: Announcement, 15 Jul 2004     Satish Thatte, 18 Jul 2004     Yaron Y. Goland, 19 Jul 2004     Chris Keller, 19 Jul 2004     Yaron Y. Goland, 20 Jul 2004     Satish Thatte, 21 Jul 2004     Satish Thatte, 21 Jul 2004     Satish Thatte, 21 Jul 2004     Satish Thatte, 29 Jul 2004     Yaron Y. Goland, 29 Jul 2004     Satish Thatte, 29 Jul 2004     Proposed resolution (Yaron Y. Goland, 16 Sep 2004)
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    18 Jul 2004 - fields: Links;    19 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links;    16 Sep 2004 - fields: Links, Status, Proposed resolution;    23 Sep 2004 - fields: Status, Proposed resolution, Resolution;    25 Nov 2004 - fields: In spec


Issue 138: Properties of type element

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Properties are currently restricted to be simpleTypes but in many cases being able to pull out structured information is extraordinarily valuable to users. One can imagine properties like 'list or order addresses' that goes through all the orders in a PO and returns a list of all the address structures.
Submitter's proposal: We should allow properties to be both simpleTypes and complexTypes.
Links: Announcement, 15 Jul 2004     Satish Thatte, 18 Jul 2004     Yaron Y. Goland, 19 Jul 2004     Satish Thatte, 21 Jul 2004     Dieter Koenig1, 13 Sep 2004     Yaron Y. Goland, 14 Sep 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    18 Jul 2004 - fields: Links;    19 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    13 Sep 2004 - fields: Links;    15 Sep 2004 - fields: Links

Issue 139: PartnerLink Semantics

Status: open
Date added: 15 Jul 2004
Categories: Partner links
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: When a partner is created are its myRole and partnerRole values un-initialized? If a deployment admin doesn't init the values at deployment time are they allowed to stay un-initialized? When a message is received what if anything is done with the partnerRole EPR? This issue is meant as a general bucket for the issues that came up in the issue 126 conversation about exactly how it is that partnerLinks work in BPEL.
Links: Announcement, 15 Jul 2004     Yaron Y. Goland, 27 Jul 2004     Satish Thatte, 29 Jul 2004     Yaron Y. Goland, 29 Jul 2004     Satish Thatte, 30 Jul 2004     Yaron Y. Goland, 3 Aug 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    28 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links;    31 Jul 2004 - fields: Links;    4 Aug 2004 - fields: Links

Issue 140: Until Activity

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Add support for until as a complement to while.
Submitter's proposal:
  <until standard-attributes>
        standard-elements
        <condition expression-language="URI">
           bool-expr
        </condition>
        activity
</until>
This would effectively be a macro for:
<scope>
    activity1
    <while>
       <condition>bool-expr</condition>
       activity1
    </while>
</scope>

Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 141: Standard Fault Format

Status: open
Date added: 15 Jul 2004
Categories: Fault handling
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: When we specify BPEL faults it would be goodness if implementations had a standard, portable, way of specifying platform specific data inside of the fault.
Submitter's proposal: We should introduce a standard fault format to be used with BPEL faults. All BPEL generated faults would be defined to have bodies and those bodies would have some kind of extensible internal structure. This would have no affect on WSDL generated faults (e.g. SOAP faults). This is really a best practice.
Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 142: Break & Continue

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation, State management
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: What if one is deep inside of a flow and want to exit 'successfully' as opposed to being forced to throw a fault? What if one is deep inside of a while and want to immediately 'successfully' continue to the next iteration as opposed to being forced to throw a fault?
Submitter's proposal: Currently if one needs to quickly 'jump' from one part of the code to another in a structured way the only option are faults. But faults, appropriately enough, imply error, which involve things like fault handlers, getting rid of compensation handlers, logging, etc. We really need a way to exit or continue 'successfully'. This is where break and continue would be very useful. We should probably also include named forms of break/continue.
Proposed resolution: Satish Thatte, 17 Sep 2004
Links: Announcement, 15 Jul 2004     Dieter Koenig1, 20 Jul 2004     Monica J. Martin, 21 Jul 2004     Dieter Koenig1, 21 Jul 2004     Proposed resolution to 6 and 142 (Satish Thatte, 17 Sep 2004)     Proposal withdrawn, conf call 8 Dec 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    20 Sep 2004 - fields: Categories;    2 Dec 2004 - fields: Status, Proposed resolution, Links;    8 Dec 2004 - fields: Status, Links

Issue 143: StaticSwitch Activity

Status: open
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: A static switch is a switch in which the values of the cases are static values rather than expressions. Besides being a common form of switch it is an easily validated expression for providing control flow over enumerated values.
Submitter's proposal:
<staticSwitch standard-attributes>
    standard-elements
    <condition expression-language="URI">general-expr</condition>
    <case value="xs:string">+
       activity
    </case>
    <otherwise>
       activity
    </otherwise>
</staticSwitch>
This is effectively a macro for:
<switch>
    <case>+
       <condition>general-expr = string</condition>
       activity
    </case>
    <otherwise>
       activity
    </otherwise>
</switch>

Links: Announcement, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links

Issue 144: Defining Undefined Behaviors

Status: open
Date added: 15 Jul 2004
Categories: Specification editing
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Generally it's a bad idea to have undefined behaviors in a language. It leads to gray spots where programmers, often without realizing it, end up relying on a particular implementations handling of 'undefined' and so unwittingly create non-portable code. While it is true that there will be situations where we will have to leave things undefined we should work hard to make those the exception.

For example, Section 6.5 of the spec states "A receive activity for an inbound request/response operation is said to be open if that activity has been performed and no corresponding reply activity has been performed. If the process instance reaches the end of its behavior, and one or more receive activities remain open, then the status of the instance becomes undefined."

Should this be undefined or should a fault be required to be thrown followed by the process exiting? The actual solution isn't as important as providing a well defined behavior.
Submitter's proposal: Put together a table of all undefined behaviors and then review them to decide if they should be changed. It would be useful to put the table into the spec as an appendix in order to help programmers and implementers know exactly which behaviors are undefined.
Links: Announcement, 15 Jul 2004     Alex Yiu, 15 Jul 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links


Issue 145: Properties on Non-Message Variables

Status: resolved
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: Properties are a very useful mechanism for extracting information from complex values in a simple fashion. Their utility is not just limited to WSDL message variables.
Submitter's proposal: We should allow for property aliases to be defined in the WSDL for XML schema types. Then any variable that is defined with a type that has a property alias defined for it will have the associated property made available for it.
Resolution: Proposed in Yaron Goland, 15 Dec 2004, approved Hawthorne f-t-f, 15 Dec 04 with note that further work is required on specific language

Allow for the definition of properties on non-WSDL messages.

Rationale: Properties represent a fundamental design approach where information in potentially very complex XML variables is made available in a simple name/value fashion. This feature is just as useful for regular XML variables as it is for WSDL messages and should be available for both.

Changes Required: Change propertyAlias to make messageType and part attributes optional and introduce element and type attributes. Specify that getVariableProperty can take arbitrary BPEL variables as arguments. Clarify the matching rules for properties/propertyAliases/variables. Update the terminology to make message properties a type of variable properties. Also fixed a bug where there is an ambiguity as to what happens if two propertyaliases for the same property on the same message type, the new text requires this to be statically detected and rejected.

Section 1:

From: WS-BPEL uses a notion of message properties to identify protocol-relevant data embedded in messages.

To: WS-BPEL uses a notion of message properties, which are a type of variable property, to identify protocol-relevant data embedded in messages.

Section 6.4:

From: Process definitions also rely on other constructs such as partner link types, message properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.

To: Process definitions also rely on other constructs such as partner link types, variable properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.

Section 8:

Change title to “Variable Properties”

Note: There are references in the spec to (see Message Properties) this will need to be changed to (see Variable Properties)

Section 8.1:

Create section 8.1.1 titled “Motivation for Message Properties”, insert current section 8.1 text there.

Create section 8.1.2 titled “Motivation for Variable Properties” with the following value:

Message properties are an instance of a more generic mechanism, variable properties. All variables in BPEL can have properties defined on them. Properties are useful on non-message variables as a way to isolate the BPEL process’s logic from the details of a particular variable’s definition. Using properties a BPEL process can isolate its variable initialization logic in one place and then set and get properties on that variable in order to manipulate it. If the variable’s definition is later changed the bulk of the BPEL process definition that manipulates that variable can remain unchanged.

Section 8.2:

From: “Properties can occur anywhere in a message, including in the message context.”

To “Properties can occur anywhere in a variable.”

Insert the following paragraph after the existing paragraph that begins “In correlation, the property name must have global significance…”:

Even in the general case of properties on XML typed WS-BPEL variables the property name should maintain its generic nature. The name is intended to identify a certain kind of value, often with an implied semantic. Any variable the property is available on is therefore expected to provide a value that meets not just the syntax of the property definition but also its semantics.

End section 8.2 after the schema for property definitions (which this proposal does not change).

Insert section 8.3 titled "Defining Property Aliases", the content of this new section is based on the text that was originally in section 8.2 after the property schema definition:

Properties used in business protocols are typically embedded in application-visible variables. The notion of aliasing is introduced to map a global property to a field in a specific message part or variable value. The property name becomes an alias for the message part and/or location, and can be used as such in Expressions and Assignment in abstract business processes. As an example, consider the following WSDL message definition:

1234567890123456789012345678901234567890123456789012345678901234567890 
         1         2         3         4         5         6 
<definitions name="messages" 
        targetNamespace="http://example.com/taxMessages.wsdl" 
        xmlns:txtyp="http://example.com/taxTypes.xsd" 
        xmlns="http://schemas.xmlsoap.org/wsdl/"> 
        <!-- define a WSDL application message --> 

<message name="taxpayerInfoMsg">

<part name="identification" element="txtyp:taxPayerInfoElem"/>

</message>

...

</definitions>

The definition of a global property and its location in a particular field of the message are shown in the next WSDL fragment:
1234567890123456789012345678901234567890123456789012345678901234567890 
         1         2         3         4         5         6 
<definitions name="properties" 
        targetNamespace="http://example.com/properties.wsdl" 
        xmlns:tns="http://example.com/properties.wsdl" 
        xmlns:txtyp="http://example.com/taxTypes.xsd" 
        xmlns:txmsg="http://example.com/taxMessages.wsdl" 
        xmlns="http://schemas.xmlsoap.org/wsdl/"> 

<!-- define a correlation property -->

<bpws:property name="taxpayerNumber" type="txtyp:SSN"/>

...

<bpws:propertyAlias propertyName="tns:taxpayerNumber"

messageType="txmsg:taxpayerInfoMsg" part="identification">

<query>

/txtyp:taxPayerInfoElem/txtyp:socialsecnumber

</query> </bpws:propertyAlias>

<bpws:propertyAlias propertyName="tns:taxpayerNumber" element="txtyp:taxPayerInfoElem"> <query>

/txtyp:taxPayerInfoElem/txtyp:socialsecnumber

</query> </bpws:propertyAlias> </definitions>

The first bpws:propertyAlias defines a globally named property tns:taxpayerNumber as an alias for a location in the identification part of the message type txmsg:taxpayerInfo.

The second bpws:propertyAlias provides a second definition for the same globally named property tns:taxpayerNumber but this time as an alias for a location inside of the element txtyp:taxPayerInfoElem.

The presence of both aliases means that it is possible to retrieve the social security number from both a variable holding a message of messageType txmsg:taxpayerInfo as well as an element defined using txtyp:taxPayerInfoElem.

The syntax for a propertyAlias definition is:

1234567890123456789012345678901234567890123456789012345678901234567890 

1 2 3 4 5 6

<definitions name="ncname" ... > <bpws:propertyAlias propertyName="qname" messageType="qname"? part="ncname"?

type="qname"? element="qname"?>

<query queryLanguage="anyURI"?>?

... queryString ...

</query>

</bpws:propertyAlias> ... </wsdl:definitions>

A property alias element MUST use one of the three following combinations of attributes:

When a propertyAlias is used with the messageType/part combination then the property MUST be available on all BPEL variables where the qname value used in the messageType attribute on the declaration of both the variable and the propertyAlias are identical. The part attribute and query element is applied against the BPEL messageType variable to either set or get the property variable in the same way that the part attribute and query element are used in the first from and to specs in copy assignments.

If a propertyAlias is used with a type attribute then the property MUST be available on all BPEL variables where the qname value used in the type attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against BPEL variables defined using a type.

If a propertyAlias is used with an element attribute then the property MUST be available on all BPEL variables where the qname value used in the element attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against BPEL variables defined using an element definition.

A BPEL process MUST NOT be accepted for processing if it defines two or more propertyAlias’s for the same property name and BPEL variable type. For example, it is not legal to define two propertyAlias’s for the property taxpayernumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two propertyAliases on the same element qname and property name value or two propertyAliases on the same type qname and property name value.

Section 9.0

From: Abstract processes are restricted to limited manipulation of values contained in message properties but are permitted to use nondeterministic values to reflect the consequences of hidden private behavior.

To: Abstract processes are restricted to limited manipulation of values contained in variable properties but are permitted to use nondeterministic values to reflect the consequences of hidden private behavior.

Section 9.1

From: If the given property does not appear in any of the parts of the variable's message type, then the semantics of the process is undefined.

To: If the referenced property is not defined or if there does not exist a propertyAlias to associate the property with the referenced variable then the semantics of the process is undefined.

Section 9.3

From: The third from-spec and to-spec variants allow explicit manipulation of message properties (see Message Properties) occurring in variables.

To: The third from-spec and to-spec variants allow explicit manipulation of variable properties (see Variable Properties) occurring in variables.

Section 10.2

From: They are abstract in the sense that their occurrence in messages needs to be separately specified (see Message Properties).

To: They are abstract in the sense that their occurrence in variables needs to be separately specified (see Variable Properties).

Section 14.1

From: If the given property does not appear in any of the parts of the variable's message type or the given property definition selects a node set of a size other than one, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.

To: If the referenced property is not defined, if there does not exist a propertyAlias to associate the property with the referenced variable or if the given property definition selects a node set of a size other than one, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.
Links: Announcement, 15 Jul 2004     Proposed resolution (Yaron Y. Goland, 10 Dec 2004)     Ron Ten-Hove, 10 Dec 2004     General agreement at Hawthorne f-t-f     Proposed resolution (Yaron Goland, 15 Dec 2004)     Diane Jordan, 15 Dec 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    10 Dec 2004 - fields: Links, Status, Proposed resolution;    11 Dec 2004 - fields: Links;    15 Dec 2004 - fields: Links, Status, Proposed resolution;    16 Dec 2004 - fields: Links, Status, Proposed resolution, Resolution


Issue 146: Making tVariable Extensible

Status: resolved
In spec: 8 Sept 2004
Date added: 15 Jul 2004
Categories: Syntax and validation
Date submitted: 15 July 2004
Submitter: Yaron Y. Goland
Description: The schema currently says:
<complexType name="tVariable">
<!-- variable does not allow extensibility elements
because otherwise its content model would be non-deterministic -->
	<attribute name="name" type="NCName" use="required"/>
	<attribute name="messageType" type="QName" use = "optional"/>
	<attribute name="type" type="QName" use = "optional"/>
	<attribute name="element" type="QName" use = "optional"/>
	<anyAttribute namespace="##other" processContents="lax"/>
</complexType> 
Which means that one cannot add new values into tVariable. :Submitter's proposal: It is unclear to me why restricting the extensibility of tVariable is necessary to make the model deterministic. An ANY element would fit in just fine so we should add it.
Resolution: Proposed in Yaron Y. Goland, 13 Aug 2004, decided at conf call, 18 Aug 2004

Change the definition of tVariable to:

<complexType name="tVariable">
     <complexContent>
        <extension base="bpws:tExtensibleElements">
           <attribute name="name" type="NCName" use="required"/>
           <attribute name="messageType" type="QName" use="optional"/>
           <attribute name="type" type="QName" use="optional"/>
           <attribute name="element" type="QName" use="optional"/>
        </extension>
     </complexContent>
</complexType>

Links: Yaron Y. Goland, 3 Mar 2004     Announcement, 15 Jul 2004     Yaron Y. Goland, 31 Jul 2004     Eckenfels. Bernd, 1 Aug 2004     Francisco Curbera, 2 Aug 2004     Yaron Y. Goland, 3 Aug 2004     Francisco Curbera, 4 Aug 2004     Proposed resolution (Yaron Y. Goland, 13 Aug 2004)     Eckenfels. Bernd, 13 Aug 2004     Yaron Y. Goland, 16 Aug 2004     Yaron Y. Goland, 19 Aug 2004     Eckenfels. Bernd, 19 Aug 2004
Changes: 15 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    31 Jul 2004 - fields: Links;    1 Aug 2004 - fields: Links;    2 Aug 2004 - fields: Links;    4 Aug 2004 - fields: Links;    14 Aug 2004 - fields: Links, Status, Proposed resolution;    15 Aug 2004 - fields: Links;    17 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Status, Proposed resolution, Resolution;    19 Aug 2004 - fields: Links;    15 Sep 2004 - fields: In spec

Issue 147: Serial and Parallel For-Each

Status: open
Date added: 16 Jul 2004
Categories: Syntax and validation, State management, Asynchronous operations
Date submitted: 15 June 2004
Submitter: Yaron Y. Goland
Description: For-each is a very common control structure that has special appropriateness to BPEL where one can routinely expect BPELs to need to iterate through XML structures. One can easily imagine two flavors of for-each. Serial and parallel. Note: These same ideas have been proposed in issue 63 and issue 4 but both of those issues could be resolved in ways that do not necessarily use the for-each construct. Therefore I am proposing for-each on its own. If 63 and 4 are closed by introducing serial and parallel for-each then this issue can also be closed.
Submitter's proposal:
<foreach iteratorVariableName="ncname" iteratorVariableType="qname"\
           parallel="xs:Boolean" standard-attributes>
     standard-elements
     <expression expressionLanguage="anyURI">...</query>
     activity
</foreach>
The expression element would be responsible for returning a node-set with 0 or more nodes in it. Each node MUST be of the type specified by iteratorVariableType.

If parallel equals false then each node would be assigned, serially and in document order, to the variable created in an implicit local scope by the attribute iteratorVariableName and the activity would be executed. After the activity successfully completes the variable would be assigned to the next node and the activity run again.

If parallel equals true then a series of parallel scopes, with the same operational semantics as parallel executing event handlers, equal in number to the number of nodes in the node-set would be created and each node would be assigned to a variable local to each of the scopes.

Note that the scope in which the iterator variable is defined is local to the foreach activity and does not contain either an implicit fault or compensation handler. The lack of these handlers is very similar to the logic that was discuss at the 6/2004 F2F for issue 126.

For example:

foreach iteratorVariableName="anOrder" iteratorVariableType="b:ar"/
              expression 
              expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116" 
			  parallel="false"
        $orderManifest/somePart/ordermanifest/orders
     ...

Would be equivalent to:

scope
    variables
       variable name="anOrder" type="b:ar"
       variable name="currentInstanceNum" type="xs:int"
    sequence
       assign
          replace
             from expressionLanguage="static"
                "1"
             to expressionLanguage="xpath"
                $currentInstanceNum
       while
          condition expressionLanguage="xpath"
             $currentInstanceNum <= count($orderList/somePart/ordermanifest/orders)
          sequence
             assign
                replace
                   from expressionLanguage="xpath"
                      $orderList/somePart/(ordermanifest/orders)[$currentInstanceNum]
                   to expressionLanguage="xpath"
                      $anOrder
             assign
                replace
                  from expressionLanguage="xpath"
                     $currentInstanceNum+1
                  to expressionLanguage="xpath"
                     $currentInstanceNum
             ...

Links: Yaron Y. Goland, 25 Mar 2004 Yaron Y. Goland, 25 Mar 2004     Announcement, 16 Jul 2004     Frank.Leymann@t-online.de, 16 Jul 2004     Yaron Y. Goland, 16 Jul 2004     Alex Yiu, 17 Jul 2004     Alex Yiu, 17 Jul 2004     Frank.Leymann@t-online.de, 17 Jul 2004     Frank.Leymann@t-online.de, 17 Jul 2004     Alex Yiu, 18 Jul 2004     Yaron Y. Goland, 19 Jul 2004     Yaron Y. Goland, 19 Jul 2004     Yaron Y. Goland, 19 Jul 2004     Danny van der Rijn, 19 Jul 2004     Dieter Roller, 20 Jul 2004     Yaron Y. Goland, 20 Jul 2004     Alex Yiu, 20 Jul 2004     Assaf Arkin, 21 Jul 2004     Maciej Szefler, 4 Aug 2004
Changes: 16 Jul 2004 - new issue;    16 Jul 2004 - fields: Links;    17 Jul 2004 - fields: Links;    18 Jul 2004 - fields: Links;    19 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    4 Aug 2004 - fields: Links;    20 Sep 2004 - fields: Categories

Issue 148: Explicitly state that solicit/response & notification aren't supported by BPEL

Status: open
Date added: 17 Jul 2004
Categories: Specification editing
Date submitted: 16 July 2004
Submitter: Yaron Y. Goland
Description: There is an explicit assumption in the BPEL spec that solicit/response and notification WSDL MEPs are not supported by BPEL. We need to make this assumption explicit.

What isn't clear is what we should do if someone gives us a WSDL with a solicit/response or notification. Should we ignore it? Should we throw an error? If only one role in a partnerLink has a WSDL should we transmute the solicit/response or notification on that WSDL into a mirror image WSDL for the other role using request/response or one way? What if both roles have a fully specified WSDL? In that case should we validate that the solicit/response or notification on one role's WSDL is matched with a request/response or one way on the other role's WSDL? If there isn't a matching pair should we create a match on the other role's WSDL?
Submitter's proposal: I suspect the simplest and most robust solution is that if BPEL is given a WSDL with a solicit/response or notification then an error MUST be thrown. I don't like ignoring things in cases like this, it causes confusion. If a tool wants to be really smart and do pre-processing to turn solicit/response or notification into a mirror image WSDL that's fine but it's also out of scope for BPEL. I think that all BPEL should care about is that when the WSDLs are submitted they don't have any solicit/response or notification operations.
Links: Announcement, 17 Jul 2004
Changes: 17 Jul 2004 - new issue;    17 Jul 2004 - fields: Links


Issue 149: adding formal <documentation> support to BPEL

Status: resolved
In spec: 8 Sept 2004
Date added: 20 Jul 2004
Categories: Syntax and validation
Date submitted: 20 July 2004
Submitter: Alex Yiu
Description: It would be a good idea to add a formal <documentation> element to all BPEL extensible elements. The element pattern will be based on XSD/annotation/documentation (which is slightly different from WSDL/documentation pattern). Hopefully, this suggestion is not controversial.
Submitter's proposal: Here is the suggested schema changes:

    <import namespace="http://www.w3.org/XML/1998/namespace" 
        schemaLocation="http://www.w3.org/2001/xml.xsd" />
     <element name="documentation" id="documentation">
        <complexType mixed="true">
            <sequence minOccurs="0" maxOccurs="unbounded">
                   <any processContents="lax"/>
            </sequence>
            <attribute name="source" type="anyURI"/>
            <attribute ref="xml:lang"/>
        </complexType>
    </element>
    <complexType name="tExtensibleElements">
        <annotation>
            <documentation>
        This type is extended by other component types
        to allow elements and attributes from
        other namespaces to be added.
       </documentation>
        </annotation>
        <sequence>
            <element ref="bpws:documentation" minOccurs="0" maxOccus="unbounded" />
            <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
        <anyAttribute namespace="##other" processContents="lax"/>
    </complexType>

Resolution: Proposed in Alex Yiu, 30 Jul 2004, decided at conf call, 18 Aug 2004

Add <documentation> element to all BPEL extensible elements.

Description of <documentation> to be added to the specification text:

The content of <documentation> are for human-consumption. Example types for those content are: plain text, HTML and XHTML. On the other hand, tool-implementation specific information (e.g. the graphical layout details) should be added through elements and attributes of other namespaces, using the general BPEL extension mechanism. (i.e. bpws:tExtensibleElements).

In the schema, add as shown here in bold:

    <import namespace="http://www.w3.org/XML/1998/namespace" 
        schemaLocation="http://www.w3.org/2001/xml.xsd" />
     <element name="documentation" id="documentation">
        <complexType mixed="true">
            <sequence minOccurs="0" maxOccurs="unbounded">
                   <any processContents="lax"/>
            </sequence>
            <attribute name="source" type="anyURI"/>
            <attribute ref=<a class="moz-txt-link-rfc2396E" href="xml:lang">"xml:lang"</a>/>
        </complexType>
    </element>
    <complexType name="tExtensibleElements">
        <annotation>
            <documentation>
        This type is extended by other component types
        to allow elements and attributes from
        other namespaces to be added.
       </documentation>
        </annotation>
        <sequence>
            <element ref="bpws:documentation" minOccurs="0" maxOccus="unbounded" />
            <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
        <anyAttribute namespace="##other" processContents="lax"/>
    </complexType>

Links: Announcement, 20 Jul 2004     Yaron Y. Goland, 20 Jul 2004     Alex Yiu, 20 Jul 2004     Yaron Y. Goland, 22 Jul 2004     Alex Yiu, 22 Jul 2004     Tony Fletcher, 28 Jul 2004     Francisco Curbera, 28 Jul 2004     Satish Thatte, 29 Jul 2004     Alex Yiu, 29 Jul 2004     Alex Yiu, 30 Jul 2004     Tony Fletcher, 24 Aug 2004     Alex Yiu, 24 Aug 2004     Tony Fletcher, 24 Aug 2004
Changes: 20 Jul 2004 - new issue;    20 Jul 2004 - fields: Links;    21 Jul 2004 - fields: Links;    23 Jul 2004 - fields: Links;    28 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    31 Jul 2004 - fields: Links;    14 Aug 2004 - fields: Links, Status, Proposed resolution;    18 Aug 2004 - fields: Status, Proposed resolution, Resolution;    24 Aug 2004 - fields: Links;    15 Sep 2004 - fields: In spec

Issue 150: Message variables on invoke and reply

Status: open
Date added: 20 Jul 2004
Categories: Syntax and validation
Date submitted: 20 July 2004
Submitter: Yaron Y. Goland
Description: The inputVariable is currently marked as optional on invoke activities but that doesn't make sense as we always require a message object in order to send a message.
Submitter's proposal: As things stand we should make the inputVariable mandatory. However, an alternative approach would be to have a friendly amendment to issue 12 : XML types and WS Interactions to cover the case of messages with no parts. Both the WSDL 1.1 schema and WS-I seem to allow WSDL messages that have no parts. In that case a reasonable shortcut would be to make inputVariable optional on invoke as well as making both the faultName and variable attributes fully optional (as opposed to mutually exclusive) on reply in order to handle the 'no parts' case.
Links: Announcement, 20 Jul 2004
Changes: 20 Jul 2004 - new issue;    21 Jul 2004 - fields: Links

Issue 151: Allow a new process instance to be created by "pick onAlarm until"

Status: resolved
In spec: no change
Date added: 26 Jul 2004
Categories: State management
Date submitted: 23 July 2004
Submitter: Ugo Corda
Description: Currently the spec does not allow a Pick with createInstance=yes when alarms are specified. I don't see a good rationale for having this restriction in the case onAlarm specifies a particular time for the associated activities to occur ("until" case).

Relaxing this restriction would be useful when we want a process instance to start at a particular time, possibly on a periodical base. An alternative way of achieving the same effect would be by defining a receive from a "partner" representing the deployment environment, and having the environment itself send a message at the appropriate time. But I think it would be more clear if we use the pick-onAlarm construct instead.
Revisitable: yes
Resolution: Proposed in Ugo Corda, 7 Sep 2004, decided conf call, 15 Sept 2004

Close this issue with no change to the spec. Mark as revisitable.
Links: Ugo Corda, 22 Jul 2004     Dieter Koenig1, 23 Jul 2004     Dieter Roller, 23 Jul 2004     Ugo Corda, 23 Jul 2004     Ugo Corda, 23 Jul 2004     Ron Ten-Hove, 23 Jul 2004     Prasad Yendluri, 23 Jul 2004     Prasad Yendluri, 23 Jul 2004     Announcement, 26 Jul 2004     Eckenfels. Bernd, 26 Jul 2004     Yaron Y. Goland, 28 Jul 2004     Monica J. Martin, 28 Jul 2004     Satish Thatte, 29 Jul 2004     Eckenfels. Bernd, 29 Jul 2004     Ugo Corda, 29 Jul 2004     Ugo Corda, 29 Jul 2004     Satish Thatte, 29 Jul 2004     Yaron Y. Goland, 29 Jul 2004     Yaron Y. Goland, 29 Jul 2004     Ugo Corda, 29 Jul 2004     Ugo Corda, 29 Jul 2004     Proposed resolution (Ugo Corda, 7 Sep 2004)
Changes: 26 Jul 2004 - new issue;    26 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links;    7 Sep 2004 - fields: Links, Status, Proposed resolution;    15 Sep 2004 - fields: Status, Proposed resolution, Resolution, Revisitable, In spec


Issue 152: Clarification of usage of "reference-scheme" attribute of "service-ref" element

Status: resolved
In spec: 3 Dec 2004
Date added: 27 Jul 2004
Categories: Syntax and validation
Date submitted: 26 July 2004
Submitter: Alex Yiu
Description: This is a follow-up issue for Issue 34, which we passed to introduce a "bpws:service-ref" element wrapper to contain details of the EPR used by partnerLink. There was some discussion on how to use the "reference-scheme" attribute of the "bpws:service-ref" wrapper element.

Here are some suggested usage:

(A) Keep it required as mentioned in original proposal of Issue 34:

The “bpws:service-ref” has a required attribute called “reference-scheme” to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of bpws:service-ref. Most likely, the URI of reference scheme will have the same value for the namespace URI of the child element of bpws:service-ref. But they are not necessarily the same.

(B) Make it optional:

The “bpws:service-ref” has an optional attribute called “reference-scheme” to to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of bpws:service-ref.

Most likely, the URI of reference scheme and the namespace URI of the child element of bpws:service-ref are not necessarily the same. Typically, this optional attribute is used ONLY when the child element of the “bpws:service-ref” is ambiguous by itself. The optional attribute supplies further information to disambiguate the usage of the content.

Example: different treatments of wsdl:service element


Submitter's proposal:

I personally prefer (B) over (A).
Resolution: Proposed in Alex Yiu, 11 Aug 2004, approved by Web ballot (ended 29 Oct 2004)

Make the "reference-scheme" attribute of of "service-ref" element optional.

See proposal email for details. The ballot was multiple choice (see also Web ballot (ended 29 Oct 2004) , Web ballot (ended 29 Oct 2004) , Web ballot (ended 29 Oct 2004) , resolved by condorcet counting
Links: Announcement, 27 Jul 2004     Yaron Y. Goland, 28 Jul 2004     Francisco Curbera, 28 Jul 2004     Alex Yiu, 28 Jul 2004     Satish Thatte, 29 Jul 2004     Satish Thatte, 29 Jul 2004     Yaron Y. Goland, 29 Jul 2004     Alex Yiu, 6 Aug 2004     Yaron Y. Goland, 9 Aug 2004     Alex Yiu, 9 Aug 2004     Proposal to vote (Alex Yiu, 11 Aug 2004)     Yaron Y. Goland, 11 Aug 2004     Alex Yiu, 12 Aug 2004     Yaron Y. Goland, 13 Aug 2004     Martin Chapman, 25 Aug 2004     Yaron Y. Goland, 26 Aug 2004     Martin Chapman, 26 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Ron Ten-Hove, 27 Aug 2004     Martin Chapman, 31 Aug 2004     Kristofer Agren, 1 Sep 2004     Kristofer Agren, 1 Sep 2004     New proposal to vote (Francisco Curbera, 2 Sep 2004)     Ron Ten-Hove, 2 Sep 2004     Alex Yiu, 2 Sep 2004     Francisco Curbera, 3 Sep 2004     Francisco Curbera, 3 Sep 2004     Martin Chapman, 3 Sep 2004     Ron Ten-Hove, 7 Sep 2004     Chris Keller, 7 Sep 2004     Ron Ten-Hove, 8 Sep 2004     Chris Keller, 8 Sep 2004     Alex Yiu, 8 Sep 2004     Chris Keller, 8 Sep 2004     Yaron Y. Goland, 9 Sep 2004     Yaron Y. Goland, 9 Sep 2004     Martin Chapman, 9 Sep 2004     Ron Ten-Hove, 9 Sep 2004     Yaron Y. Goland, 14 Sep 2004     Proposed resolution (Francisco Curbera, 21 Oct 2004)     Martin Chapman, 5 Nov 2004     Diane Jordan, 5 Nov 2004
Changes: 27 Jul 2004 - new issue;    27 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links;    7 Aug 2004 - fields: Links;    9 Aug 2004 - fields: Links;    10 Aug 2004 - fields: Links;    11 Aug 2004 - fields: Links;    12 Aug 2004 - fields: Links;    14 Aug 2004 - fields: Links;    18 Aug 2004 - fields: Status, Proposed resolution;    26 Aug 2004 - fields: Links;    27 Aug 2004 - fields: Links;    31 Aug 2004 - fields: Links;    2 Sep 2004 - fields: Links;    3 Sep 2004 - fields: Links;    7 Sep 2004 - fields: Links;    8 Sep 2004 - fields: Links   ;    9 Sep 2004 - fields: Proposed resolution (corrected by hand, submitted 2 Sep), Links;    15 Sep 2004 - fields: Links, Proposed resolution;    21 Oct 2004 - fields: Links, Status, Proposed resolution;    6 Nov 2004 - fields: Links;    8 Nov 2004 - fields: Status, Proposed resolution, Resolution;    4 Dec 2004 - fields: In spec


Issue 153: getVariableData xpath function should return node sets of any size

Status: open
Date added: 27 Jul 2004
Categories: Data handling
Date submitted: 20 July 2004
Submitter: Ugo Corda
Description: The getVariableData xpath function should return node sets of any size (0, 1, >1) instead of throwing a selectionFailure fault in cases where the resulting node set size is not one.

Here are two use cases to explain the request:

(It is possible the resolution of issue 103 : Standardizing $varName syntax for XPath to refer to a BPEL variable will address this issue, in which case this issue can be dropped)
Links: Announcement, 27 Jul 2004
Changes: 27 Jul 2004 - new issue;    27 Jul 2004 - fields: Links


Issue 154: doc/lit & multiple body parts

Status: open
Date added: 28 Jul 2004
Categories: Related standards
Date submitted: 27 July 2004
Submitter: Yaron Y. Goland
Description: In theory it is legal in WSDL to define a doc/lit encoding where the body parts are complexTypes. Let us say there are two body parts. The first body part is a complexType which defines a sequence that ends in xs:any. In that case when a message arrives there is no well defined way to separate the first and second body parts, the situation is ambiguous.
Submitter's proposal: One possible solution to this problem is to state that if a doc/lit has multiple body parts then they MUST be composable in an unambiguous manner. But defining that is going to be a challenge given the.... um.... issues.... with XML Schema. So perhaps we want a simpler solution.

WS-I addressed this issue in R2204 by requiring that all parts in a doc/lit MUST be element definitions. However I am told that the most common behavior previous to WS-I was to only allow doc/lit messages to have a single body part which could be a complexType. I suspect we need to support both of these scenarios. So why don't we just specify in the spec that any doc/lit WSDL binding MUST either have a single body part or if multiple body parts are used then all the parts MUST be element definitions?
Links: Announcement, 28 Jul 2004     Kevin Liu, 28 Jul 2004     Yaron Y. Goland, 29 Jul 2004
Changes: 28 Jul 2004 - new issue;    28 Jul 2004 - fields: Links;    29 Jul 2004 - fields: Links;    30 Jul 2004 - fields: Links


Issue 155: complexType Variables

Status: resolved
Date added: 28 Jul 2004
Categories: Data Handling
Date submitted: 27 July 2004
Submitter: Yaron Y. Goland
Description: BPEL variables are currently restricted to be either simpleTypes or elements. But WSDL messages consist of parts that can be defined using complexTypes. This prevents certain pretty obvious scenarios such as defining a variable with the same type as a part, manipulating the variable and then using it to initialize parts in WSDL messages.
Submitter's proposal: We should remove the restriction that the type attribute on a variable declaration can only point at a simpleType definition.
Resolution: Proposed in Yaron Y. Goland, 7 Dec 2004, decided conf call, 8 Dec 2004

Allow the type attributes on variable declarations to point to complex as well as simple types.

Rationale: WSDL message parts can be defined using complex types, in the case of WS-I RPC/literal it is actually required that WSDL message parts be defined using a type, either simple or complex. But currently doing something as simple as copying a part defined using a complex type into a variable is difficult because variables are not allowed to be complex types. Also, having complex type based variables allows code to be reused more effectively when dealing with data with the same complex type but different element names. (e.g. A same piece of code can deal with data of element "shipTo" and element "billTo" of the same "address" complex type.)

Changes Required: Mostly removing the limitation that type can only specify a simple type and specifying that the infoset for a complexType is a document information item that contains a wildcard document element (e.g. it can be anything) that then contains the actual complex type value.

Section 6.1:

Current: The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema simple types, or XML Schema elements.

Replacement: The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema types (simple or complex) or XML Schema elements.

Section 9.2:

Current: The type of each variable may be a WSDL message type, an XML Schema simple type or an XML Schema element.

Replacement: The type of each variable may be a WSDL message type, an XML Schema type (simple or complex) or an XML Schema element.

Current: Attribute type refers to an XML Schema simple type.

Replacement: Attribute type refers to an XML Schema type (simple or complex).

Delete: An XML Schema complex type must be associated with an element to be used by a BPEL4WS variable.

Insert after the paragraph which begins "The messageType, type or element attributes...": The infoset for a complexType variable consists of a document information item that contains exactly one child, an element information item which is pointed at by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification, as such an implementation MUST specify whatever legal property values it likes. However the children of the document element MUST exclusively consist of the complexType values assigned to the variable."

Section 9.3:

Current: When the variable is defined using XML Schema simple type or element, the part attribute MUST NOT be used.

Replacement: When the variable is defined using XML Schema types (simple or complex) or element, the part attribute MUST NOT be used.

Section 14.1:

Current: When only the first argument is present, the function extracts the value of the variable, which in this case must be defined using an XML Schema simple type or element.

Replacement: When only the first argument is present, the function extracts the value of the variable, which in this case must be defined using an XML Schema type (simple or complex) or element. Note that in the case of a complexType variable the document element's name cannot be generally known at design time. Therefore to refer to the contents of a complexType variable one would use an XPATH 1.0 expression of the form "/*/..."
Links: Announcement, 28 Jul 2004     Proposed resolution (Yaron Y. Goland, 7 Dec 2004)
Changes: 28 Jul 2004 - new issue;    28 Jul 2004 - fields: Links;    8 Dec 2004 - fields: Links, Status, Proposed resolution;    9 Dec 2004 - fields: Status, Proposed resolution, Resolution


Issue 156: Cleaning Up XPATH in BPEL

Status: open
Date added: 31 Jul 2004
Categories: Data Handling
Date submitted: 04 June 2004
Submitter: Yaron Y. Goland
Description: BPEL does not formally define the environment in which XPATH expressions are used within BPEL. This is actually required by the XPATH 1.0 spec which provides a check list of information to provide. I also suspect we need to tighten up our definition of Boolean, Deadline and Duration expressions. We also need to adopt the W3C standard terminology for XML - infoset.
Links: Announcement, 31 Jul 2004
Changes: 31 Jul 2004 - new issue;    31 Jul 2004 - fields: Links

Issue 157: Cleaning up copy

Status: open
Date added: 31 Jul 2004
Categories: Data Handling
Date submitted: 30 July 2004
Submitter: Yaron Y. Goland
Description: If someone wants to copy an EII to an AII what should happen? Should that always be a failure or should the system try to do something reasonable like use String() to pull data out of the EII and assign it to the AII's normalized value? This same question can be asked about all the possible combinations of information items. We need to look at the various combinations and decide what, if anything we want to do.
Links: Announcement, 31 Jul 2004
Changes: 31 Jul 2004 - new issue;    31 Jul 2004 - fields: Links

Issue 158: Changing Spec Structure from 3 part to 2 part

Status: open
Date added: 4 Aug 2004
Categories: Specification editing
Date submitted: 04 August 2004
Submitter: Yaron Y. Goland
Description: The specification currently has three main sections, a 'base' section, an 'executable' section and an 'abstract' section. This means that issues like variable handling and schema validation requirements get spread across multiple sections which makes the spec both hard to read and hard to use as a reference when implementing.
Submitter's proposal: We should restructure the specification into two parts. A first part would deal exclusively with executable BPEL and would define how executable BPEL works in a consistent manner. The second part would then define abstract BPEL, mostly in terms of how it is different than executable BPEL.
Links: Announcement, 4 Aug 2004     Danny van der Rijn, 5 Aug 2004     Francisco Curbera, 6 Aug 2004     Yaron Y. Goland, 6 Aug 2004
Changes: 4 Aug 2004 - new issue;    5 Aug 2004 - fields: Links;    6 Aug 2004 - fields: Links;    7 Aug 2004 - fields: Links

Issue 159: Ordering specification sections by dependency

Status: open
Date added: 4 Aug 2004
Categories: Specification editing
Date submitted: 04 August 2004
Submitter: Yaron Y. Goland
Description: In order to make sure that a spec is maximally readable it is very useful to create a dependency graph of major concepts presented in the spec. One can then use the graph to order the specification so that one doesn't try to explain a concept before first explaining the concepts upon which it depends. Inevitably such graphs has cycles but typically such cycles are few and can be dealt with through a combination of forward references and introductory material that provides enough overview to allow early sections to be understood without having to first read the later sections upon which they depend.
Submitter's proposal: That we produce such a graph and use it to re-order the specification.
Links: Announcement, 4 Aug 2004     Danny van der Rijn, 5 Aug 2004
Changes: 4 Aug 2004 - new issue;    5 Aug 2004 - fields: Links;    6 Aug 2004 - fields: Links

Issue 160: facilities to define XML schema validation boundary

Status: resolution proposed
Date added: 10 Aug 2004
Categories: Syntax and validation
Date submitted: 7 August 2004
Submitter: Alex Yiu
Description:

Background

Suggested Goals


Potential Solution:

How to determine whether a variable should be validated


Deployment Configuration Option

An implementation MAY provide a deployment or configuration mechanism to disable and relax the schema validation. The deployment configuration mechanism is out of the scope of this TC. (This mirrors a similar feature described in XQuery-Update Requirements Draft).

New Activity for Validating XML Data

Besides the message boundary, we would like to allow people to add explicit validation operation in BPEL.  (This mirrors  a similar feature described in XQuery-Update Requirements Draft).

<validateXML variables="ncnames" />

"variables" attribute is a list of ncnames which contain any variable visible in the current scope. The variables can be based on WSDL message type, schema element, and schema simple type.

New "validateXML" attribute for <Assign>

A new "validateXML" attribute is suggested to be added to <assign> activity:

<assign validateXML="yes|no"? >
    <copy />+
</assign>

The default of that boolean attribute is "no".

It can be seen as a convenient marco of a sequence of  <assign> and <validateXML> operations. With validateXML="yes", the <assign> activity will validate all the variables used by to-specs, which are being modified by the <assign> activities.

(This validateXML attribute pattern can be applied to other activities which creates a new variable value. e.g. the potential forEach functionality).

Standard Fault

If any validation (explicit or implicit) described above fails, a standard fault bpws:invalidData MUST be thrown by an  implementation.



References

Fragments copied from XUpdate Requirement document
[XQuery Update Requirements - Internal W3C Working Draft - 07 January 2004 ]
...
3.4.12 Validation

Updates MAY support an explicit or implicit in-place XML Schema validation

...
3.5.5 Validity at transactional boundaries

Updates MUST enforce schema validity at transactional boundaries. It MAY provide a mechanism to allow this constraint to be relaxed.

...
Proposed resolution: Alex Yiu, 15 Dec 2004
Links: Announcement, 10 Aug 2004     Danny van der Rijn, 16 Sep 2004     Alex Yiu, 21 Sep 2004     Danny van der Rijn, 22 Sep 2004     Proposed resolution (Alex Yiu, 15 Dec 2004)
Changes: 10 Aug 2004 - new issue;    10 Aug 2004 - fields: Links;    16 Sep 2004 - fields: Links;    22 Sep 2004 - fields: Links;    16 Dec 2004 - fields: Links, Status, Proposed resolution

Issue 161: Explicit conformance statements

Status: resolved
In spec: No change
Date added: 8 Sep 2004
Categories: Specification editing
Date submitted: 27 August 2004
Submitter: Tony Fletcher
Description: Add an explicit set of conformance statements, preferably in a conformance section, to the specification for 'BPEL'. The rationale and a draft proposal is given in the document attached to Tony Fletcher, 27 Aug 2004

Resolving this issue will not lead to the addition of any new features.. However, it will enhance and clarify the text in a significant manner and therefore is worth tackling at this time.

The process of adding such a conformance section will cause us to think about and address the following questions:


Revisitable: Yes
Vote announcement: on agenda for f-t-f
Links: Tony Fletcher, 24 Aug 2004     Yaron Y. Goland, 26 Aug 2004     Tony Fletcher, 26 Aug 2004     Tony Fletcher, 27 Aug 2004     Yaron Y. Goland, 27 Aug 2004     Announcement, 8 Sep 2004
Changes: 8 Sep 2004 - new issue;    8 Sep 2004 - fields: Document, Links;    15 Sep 2004 - fields: Status, Vote announcement;    29 Sep 2004 - fields: Status, In spec, Revisitable

Issue 162: Unique Activity Names for Compensate

Status: resolved
Date added: 8 Sep 2004
Categories: Syntax and validation
Date submitted: 07 September 2004
Submitter: Dieter Koenig
Date accepted: 15 September 2004
Document: Specification working draft 1.39, Chapter 13.3.3, "Invoking a Compensation Handler".
Description: Currently, there is no constraint on activity names, i.e. the activity name (standard attribute) does not have to be unique. As a result, a compensate activity may become ambigous:

scope
    compensationHandler
        compensate "A" <-- don't know which one
    scope name="A" <-- first enclosed scope
    scope name="A" <-- second enclosed scope

Submitter's proposal: Clarify that activity names used in a compensate activity must be unique within the scope.
Resolution: Proposed in Dieter Koenig1, 11 Dec 2004, amended and approved at Hawthorne f-t-f

Add text to section 13.3.3 "Invoking a Compensation Handler" to clarify that activity names used in a compensate activity must be unique within the scope.

The names of all activities directly nested (ie, not within another nested scope) within a scope will be unique.

Rationale: Currently, there is no constraint on activity names, i.e. the activity name (standard attribute) does not have to be unique. As a result, a compensate activity may become ambigous:

    scope
        compensationHandler
            compensate "A" <-- don't know which one
        scope name="A" <-- first enclosed scope
        scope name="A" <-- second enclosed scope

Links: Announcement, 8 Sep 2004     Proposed resolution (Dieter Koenig1, 11 Dec 2004)
Changes: 8 Sep 2004 - new issue;    8 Sep 2004 - fields: Links;    15 Sep 2004 - fields: Status, Date accepted;    14 Dec 2004 - fields: Links, Status, Proposed resolution;    15 Dec 2004 - fields: Status, Proposed resolution, Resolution

Issue 163: languageExecutionFault

Status: open
Date added: 22 Sep 2004
Categories: Syntax and validation
Date submitted: 22 September 2004
Submitter: Danny van der Rijn
Date accepted: 15 September 2004 (clarified 13 Oct 04)
Description: If a language that is executing subordinate to BPEL (e.g. XPATH) throws a fault, there is no current spec language that defines what to do with it. This proposal clarifies that behavior.

This arose from the discussion resolving issue 134 : Non-Integer XPATHS at the 21 Sept 2004 face-to-face meeting.
Submitter's solution: To add a new standard fault, languageExecutionFault, which is thrown if the expression language or xxx throws an unhandled fault.

Add to the end of section 14.1 "If execution of the expression language yields an unhandled fault, the standard fault languageExecutionFault is thrown."

Add to the end of section 14.3 "If execution of the query language yields an unhandled fault, the standard fault languageExecutionFault is thrown."

Question: Should this fault define a message type (or should a generic message type be defined) to carry any additional data that is received from the executing language?
Links: Announcement, 22 Sep 2004
Changes: 22 Sep 2004 - new issue;    22 Sep 2004 - fields: Links;    23 Sep 2004 - fields: Description;    14 Oct 2004 - fields: Status, Date accepted


Issue 164: Variable Types for Throw and Catch

Status: resolved
In spec: Duplicate
Date added: 23 Sep 2004
Categories: Syntax and validation
Date submitted: 23 September 2004
Submitter: Dieter Koenig1
Date accepted: 13 Oct 2004
Document: Specification working draft 1.39, Chapter 13.4, "Fault Handlers".
Description: There is a mismatch between throw and catch w.r.t. types of faultVariables.

In a throw activity, one may specify a faultVariable with a NCName of a declared BPEL variable (11.6). Such variables can be declared with exactly one of {messageType, type, element} (9.2).

In catch fault handler, one may specify a faultVariable with a faultMessageType that is a QName of a WSDL message (13.4).

As a result, one cannot catch faults that are thrown with variables declared with type or element.
Submitter's proposal: Add the ability to catch faults that have faultVariables declared with type or element, e.g.:

Option 1:

   <catch faultName="qname"? faultVariable="ncname"?
          faultVariableMessageType="qname"? faultVariableType=”qname”? faultVariableElement=”qname”? >
      ...
   </catch>

Option 2:

   <catch faultName="qname"? faultVariable="ncname"? >
      <variable name="ncname" messageType="qname"? type=”qname”? element=”qname”? />
      ...
   </catch>

Option 3:

   <catch faultName="qname"? >
      <variable name="ncname" messageType="qname"? type=”qname”? element=”qname”? />
      ...
   </catch>

Resolution: Not accepted, duplicate of issue 93 : Use of XML types in faults
Links: Announcement, 23 Sep 2004     Yaron Y. Goland, 12 Oct 2004     Dieter Koenig1, 13 Oct 2004
Changes: 23 Sep 2004 - new issue;    24 Sep 2004 - fields: Links;    13 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, In spec, Resolution, Date accepted

Issue 165: clarification of the default NS URI for expression and query language

Status: resolved
In spec: 3 Dec 2004
Date added: 23 Sep 2004
Categories: Syntax and validation, Related standards
Date submitted: 23 September 2004
Submitter: Alex Yiu
Date accepted: 13 Oct 2004
Description:

Currently, http://www.w3.org/TR/1999/REC-xpath-19991116 is used as the default value of both expression language and query language, which represents XPath 1.0.

In order for us to make use of XPath 1.0 within BPEL, the BPEL spec needs to define additional semantics for the cross-language bindings. Those details are actually specific to BPEL language in a sense. Strictly speaking, it is not appropriate to "hijack" the W3C namespace for our own use.

(This was raised by Chris Keller in the course of issue 89 : Handling Unrecognized Query/Expression Languages discussion at the face-to-face today)
Submitter's proposal:

Replace the following text in BPEL spec:

The default value for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.
with:
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. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.

See also:

I believe we still need try to get some official document from OASIS on how to use an OASIS-based URN.
Resolution: Proposed in Alex Yiu, 28 Oct 2004, amended and decided at conf call, 10 November 2004

Replace the following text in BPEL spec:

The default value for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.
with:
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. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.

The urn will be adjusted as needed when the OASIS naming procedures are finalized.
Links: Announcement, 23 Sep 2004     Peter Furniss, 23 Sep 2004     Proposed resolution (Alex Yiu, 28 Oct 2004)
Changes: 23 Sep 2004 - new issue;    24 Sep 2004 - fields: Links;    14 Oct 2004 - fields: Status, Date accepted;    28 Oct 2004 - fields: Links, Status, Proposed resolution;    11 Nov 2004 - fields: Status, Proposed resolution, Resolution;    4 Dec 2004 - fields: In spec


Issue 166: Does atomicity in assign imply variable locking?

Status: resolved
In spec: 25 Nov 04
Date added: 29 Sep 2004
Categories: Data handling
Date submitted: 27 September 2004
Submitter: Yaron Y. Goland
Date accepted: 13 Oct 2004
Description: Section 14.3 of the spec requires that assigns be atomic. But it isn't clear if the definition of the term atomic encompases placing a read and write lock on the manipulated variables during the execution of the assign. For example (stolen from Danny):
int counter
counter = 0
flow
    sequence
       counter = counter + 1;
       if (counter == 2) {
          throw "counter is 2"
       }
    sequence
       counter = counter + 1;
       if (counter == 2) {
          throw "counter is 2"
       }
If assign doesn't imply placing a read/write lock on variables referenced in the assign then it is possible for the previous code to exit without ever throwing a fault. After all, both assigns could execute simultaneously, both read in the same value (0), both add 1 and both write out the same counter value, 1 and thus both end without throwing a fault.
Submitter's proposal: Writing parallel code under the best of circumstances is very difficult. Making programmers figure out how to deal with atomic non-locking behavior (and no, that isn't necessarily a contradiction), seems perverse. The easy solution would appear to be to declare that assigns always execute in an implicit serialzable scope but this 'easy' solution causes some conceptual problems in the case that the scope the assign is a member of is itself already serializable. This edge case matters because of:
scope variableAccessSerializable="yes"
    flow
       assign
          ...
       assign
          ...

Resolution: Proposed in Yaron Y. Goland, 15 Oct 2004, decided conf call, 27 October 2004

In section 14.3

Change current text:

An important characteristic of assignment in BPEL4WS is that assignment activities are atomic.

to:

The assign activity is atomic, that is, the assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process being executed. The mechanisms used to implement the previous requirement are implementation dependent.

Links: Danny van der Rijn, 18 Sep 2004     Assaf Arkin, 18 Sep 2004     Danny van der Rijn, 20 Sep 2004     Announcement, 29 Sep 2004     , 29 Sep 2004     Danny van der Rijn, 29 Sep 2004     , 29 Sep 2004     Danny van der Rijn, 29 Sep 2004     Yaron Y. Goland, 29 Sep 2004     , 30 Sep 2004     Danny van der Rijn, 30 Sep 2004     Dieter Roller, 30 Sep 2004     andrew.francis, 30 Sep 2004     Yaron Y. Goland, 30 Sep 2004     Assaf Arkin, 30 Sep 2004     andrew.francis, 30 Sep 2004     Danny van der Rijn, 30 Sep 2004     Yaron Y. Goland, 30 Sep 2004     Danny van der Rijn, 30 Sep 2004     Yaron Y. Goland, 4 Oct 2004     Ron Ten-Hove, 5 Oct 2004     Dieter Roller, 5 Oct 2004     Assaf Arkin, 5 Oct 2004     Dieter Roller, 5 Oct 2004     Assaf Arkin, 5 Oct 2004     Eckenfels. Bernd, 5 Oct 2004     Dieter Roller, 5 Oct 2004     Danny van der Rijn, 5 Oct 2004     andrew.francis, 5 Oct 2004     Ron Ten-Hove, 5 Oct 2004     Danny van der Rijn, 5 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Frank Leymann, 6 Oct 2004     Alex Yiu, 6 Oct 2004     Ron Ten-Hove, 6 Oct 2004     andrew.francis, 6 Oct 2004     Yaron Y. Goland, 6 Oct 2004     Eckenfels. Bernd, 6 Oct 2004     Proposed resolution (Yaron Y. Goland, 15 Oct 2004)     Ron Ten-Hove, 16 Oct 2004     Eckenfels. Bernd, 18 Oct 2004     Danny van der Rijn, 18 Oct 2004     andrew.francis, 18 Oct 2004     Danny van der Rijn, 18 Oct 2004     andrew.francis, 19 Oct 2004     Ron Ten-Hove, 19 Oct 2004     Eckenfels. Bernd, 25 Oct 2004     andrew.francis, 25 Oct 2004
Changes: 29 Sep 2004 - new issue;    30 Sep 2004 - fields: Links;    1 Oct 2004 - fields: Links;    5 Oct 2004 - fields: Links;    6 Oct 2004 - fields: Links;    7 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, Date accepted;    18 Oct 2004 - fields: Links, Status, Proposed resolution;    19 Oct 2004 - fields: Links;    25 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Status, Proposed resolution, Resolution;    25 Nov 2004 - fields: In spec

Issue 167: Rethrow semantics clarification

Status: resolved
Date added: 4 Oct 2004
Categories: Syntax and validation
Date submitted: 04 October 2004
Submitter: Yuzo Fujishima
Date accepted: 13 Oct 2004
Document: WSBPEL Working Draft, September 8, 2004
Description:

The current specification needs clarification on the behavior of the rethrow activity.

For example, it is unclear that a rethrown fault can be caught by a fault handler defined inside the fault handler that has caught the fault.

Suppose we have the following process definition snippet:

  <faulthandlers>
    <catch name="FH1" faultName="x:foo">
      <sequence>
        ...
        <scope>
          <faulthandlers>
            <catch name="FH2" faultName="x:foo">
            ...
            </catch>
          </faultHandlers>
          <rethrow/>
        </scope>
      </sequence>
    </catch>
  </faultHandlers>

Will FH2 catch the rethrown fault?

Champion: Yuzo Fujishima <fujishima@bc.jp.nec.com>
Submitter's proposal:

Consider rethrow as a throw with a faultVariable attribute that specifies the implicit fault variable associated with the fault handler.

Therefore, the answer to the question above is: Yes, FH2 will catch the fault.

In addition, it should be noted that a rethrow is associated with the innermost enclosing fault handler.
Resolution: Proposed in Yuzo Fujishima, 15 Oct 2004, decided conf call, 27 October 2004

Consider a <rethrow> as a macro for a <throw> that throws the fault caught by the corresponding fault handler.

A fault handler is said to be corresponding to a <rethrow> if the handler encloses the <rethrow> without intervening fault handlers.
Links: Announcement, 4 Oct 2004     Proposed resolution (Yuzo Fujishima, 15 Oct 2004)
Changes: 4 Oct 2004 - new issue;    4 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, Date accepted;    15 Oct 2004 - fields: Links, Status, Proposed resolution;    27 Oct 2004 - fields: Status, Proposed resolution, Resolution


Issue 168: Semantics of instance creation

Status: resolved
In spec: No change
Date added: 4 Oct 2004
Categories: State management
Date submitted: 30 September 2004
Submitter: Maciej Szefler
Date accepted: 13 Oct 2004
Description: Discussions of issue 81 : Are start activities that aren't createInstance activities legal? have brought to light a certain deficiency of clarity in the current specification with respect to issue of instance creation. The present spec makes various vague and somewhat contradictory statements as to how createInstance activities should be handled.

On the one hand, the spec suggests that process creation is "implicit" and that the createInstance flag is merely an annotation that defines which message events cause an instance to be created and that once created the process instance processes all activities in the same manner largely oblivious to the value of that annotation.

On the other hand, the spec restricts the set of activities that are "initial" activities, and establishes exceptional semantics (for process-level event handlers) that could be construed to imply that createInstance activities are actually activated before any other activities, irrespective of their actual location in the process.

I posit that the former interpretation provides a concise and manageable view of the instance creation process. By making the spec consistent with it we can define execution semantics of a single process instance without reference to instance creation. We can handle instance creation simply and separately by stipulating that a process instance is created when a message event that would match one of the createInstance activities is received. This message event is "allocated" to that activity, so that when that activity is actually activated (in the normal course of process instance evaluation) it will receive the said event.

The major implication of this model on execution semantics is the elimination of the notion of "initiate" activities. This concept becomes unnecessary. One might object on the basis that without the initiate activity restrictions the following process would be perfectly legal:

   <sequence>
     <invoke .../>
     <receive createInstance="yes" .../>
   </sequence>
Such a process certainly seems objectionable. However, the details of normal execution semantics would make such a process unlikely. That is to say, the <invoke> would need to use a message variable (for the request), and that variable could not have been initialized unless some activity preceded the <invoke>. One might then object with the following:
   <sequence>
     <receive createInstance="no" .. var="foo"/>
     <invoke ... inVar="foo"/>
     <receive createInstance="yes" ..>
   </sequence>
However, in this process the first receive is invalid unless a correlation set is used. But in order to use the correlation set, it first needs to be initialized, and the only way to do that is with an invoke or a receive/pick that precedes it, so you're back to needing a <receive> to precede the <invoke>. This receive would have to have createInstance="yes" lest it run into the same problem. But if this receive had createInstance="yes" then the same annotation on the second <receive> would be invalid.

Now, one might get cleverer still and object based on the following somewhat convoluted process:

   <sequence>
     <assign> 
        <copy>
           <to variable="foo"/>
           <from> literal </from>
        </copy>
     </assign>
     <invoke ... inVar="foo"> 
        <correlation name="cset1" initiate="yes" pattern="in"/>
     </invoke>
     <receive createInstance="no" ..>
        <correlation name="cset1" initiate="no" />
     </receive>
     <receive createInstance="yes" ..>
   </sequence>
However the above construct would result in ALL process instances having the same correlation set value, which does not make any sense.

But one could still object by changing the pattern to "out" on the invoke, and asserting that the partner generates unique output messages for each invocation thereby yielding unique correlation keys. But even this very brink of the edge case forces us to change nothing in the semantics. The only significant implication is that in certain unlikely circumstances, the implementation might have to handle <invoke>s and non-createInstance <receive> before it has a chance to offload the createInstance message to the createInstance <receive> (i.e. it needs to provide a "memory" for the message that created the instance). The only plausible use case for this kind of behavior is for initialization of static content.

Finally, adopting uniform execution semantics would lead us to elimination of the exceptional language in the spec that requires that process-level alarm handlers can use data that would normally only be valid after a receive activity completes. This is not so onerous, as it is possible to move a process-level event handler into a scope following the initial receives.
Resolution: Agreed by Web ballot (ended 24 Nov 2004)

We should guarantee that an initial start activity will complete before any other activities are allowed to execute. This will prevent race conditions, prevent us from having to discuss the dispatcher, prevent a bunch of edge cases and make sure that the existing event handler model will work just fine. See email with full info at: Yaron Y. Goland, 9 Nov 2004

Add the following two sentences to section 6.5:

Amongst the start activities the particular start activity that causes a specific new process instance to be created is termed the 'initial start activity'. When a BPEL process instance is created and begins executing the initial start activity MUST fully complete execution before any other initial activity may begin execution.

Links: Announcement, 4 Oct 2004     Proposed resolution (Maciej Szefler, 18 Oct 2004)     Ugo Corda, 18 Oct 2004     Maciej Szefler, 19 Oct 2004     Ugo Corda, 19 Oct 2004     Maciej Szefler, 20 Oct 2004     Ugo Corda, 20 Oct 2004     Maciej Szefler, 20 Oct 2004     Ugo Corda, 20 Oct 2004     Danny van der Rijn, 20 Oct 2004     Ugo Corda, 20 Oct 2004     Satish Thatte, 26 Oct 2004     Maciej Szefler, 27 Oct 2004     Satish Thatte, 27 Oct 2004     Francisco Curbera, 27 Oct 2004     Maciej Szefler, 27 Oct 2004     Satish Thatte, 27 Oct 2004     Yaron Y. Goland, 27 Oct 2004     Yaron Y. Goland, 27 Oct 2004     Maciej Szefler, 27 Oct 2004     Yaron Y. Goland, 27 Oct 2004     Maciej Szefler, 29 Oct 2004     Eckenfels. Bernd, 29 Oct 2004     Satish Thatte, 29 Oct 2004     Maciej Szefler, 30 Oct 2004     Maciej Szefler, 1 Nov 2004     Yaron Y. Goland, 2 Nov 2004     Satish Thatte, 2 Nov 2004     Vinkesh.Mehta, 31 Oct 2004     Proposed resolution (Yaron Y. Goland, 9 Nov 2004)     Diane Jordan, 16 Nov 2004     Yuzo Fujishima, 17 Nov 2004     Web ballot (ends 24 Nov 2004)     Diane Jordan, 22 Nov 2004     Diane Jordan, 7 Dec 2004
Changes: 4 Oct 2004 - new issue;    5 Oct 2004 - fields: Links;    14 Oct 2004 - fields: Status, Date accepted;    18 Oct 2004 - fields: Links, Status, Proposed resolution;    19 Oct 2004 - fields: Links;    20 Oct 2004 - fields: Links;    26 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Links;    28 Oct 2004 - fields: Links;    29 Oct 2004 - fields: Links;    31 Oct 2004 - fields: Links;    2 Nov 2004 - fields: Links;    3 Nov 2004 - fields: Links;    10 Nov 2004 - fields: Links, Status, Proposed resolution;    17 Nov 2004 - fields: Links;    23 Nov 2004 - fields: Status, Links;    2 Dec 2004 - fields: Status, Resolution, In spec, Proposed resolution;    8 Dec 2004 - fields: Links

Issue 169: transition condition error handling clarification

Status: resolution proposed
Date added: 18 Oct 2004
Categories: syntax & semantics
Date submitted: 18 October 2004
Submitter: Yuzo Fujishima
Date accepted: 27 October 2004
Champion: Yuzo Fujishima
Document: WSBPEL Working Draft, September 8, 2004
Description: The current specification does not clearly enough define the handling of errors in evaluating link transition conditions.

Suppose activity A has multiple link sources S1, S2, and S3, with transition conditions, and that the transition condition of S1 is evaluated and the result is an error. The status of S1 is negative according to 12.5.1 of the specification. What will happen for S2 and S3?

E1. The transition conditions of S2 and S3 are evaluated and the status of the links are set accordingly, independently of S1.

E2. The transition conditions of S2 and S3 are not evaluated and the status of the links are set to be negative.

Further suppose that, assuming we chose E1 as the right behavior, evaluating S3's transition condition resulted in an error. Then what will happen?

F1. Only one fault will be thrown from A.

F2. Two faults, one for each error, will be thrown from A.
Submitter's proposal:

Add text to 12.5.1. to explain that the correct behaviors are E1 and F1.
Proposed resolution: Yuzo Fujishima, 7 Dec 2004
Links: Announcement, 18 Oct 2004     Proposed resolution (Yuzo Fujishima, 7 Dec 2004)     Satish Thatte, 10 Dec 2004
Changes: 18 Oct 2004 - new issue;    18 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Status, Date accepted;    7 Dec 2004 - fields: Links, Status, Proposed resolution;    10 Dec 2004 - fields: Links


Issue 170: How to handle faultcode, faultstring, and faultactor

Status: resolved
Date added: 18 Oct 2004
Categories: Syntax & semantics
Date submitted: 15 October 2004
Submitter: Yuzo Fujishima
Date accepted: 10 November 2004
Champion: Yuzo Fujishima <fujishima@bc.jp.nec.com>
Document: WSBPEL Working Draft, September 8, 2004
Description: In the current specification, there is no way to set or get faultcode, faultstring, and faultactor in sending, receiving, throwing, or catching a fault.

Even though those three elements don't appear in a WSDL definition, they (especially the faultcode) convey information that is too important just to ignore.
Submitter's proposal:

I think we have to do either of the following:

  1. Do not support faultcode, faultstring, and faultactor. Add a note to the specification telling that those are not supported. Also add the rationale and possibly recommended values of them to use by implementation in sending fault.
  2. Support faultcode, faultstring, and faultactor.

One way to support faultcode, faultstring and faultactor is as follows:

Add optional faultCodeVariable, faultStringVariable, faultActorVariable attributes to <catch>, <throw>, and <reply>. For a <catch>, the attributes specify the names of the variables to set the values to, while for the latter two, the variables to get the values from.

The default values (not the variable names) are "soap:Server", "", "" for faultcode, faultstring, faultactor, respectively.
Proposed resolution: Yaron Y. Goland, 2 Dec 2004
Resolution: Agreed at conf call, 10 November 2004

To be fixed as a bug. The implementor's note proposed in submitter's proposal A) is referred to the editing team. Yaron Goland will send a draft of the implementor's note to the main list.
Links: Announcement, 18 Oct 2004     Yaron Y. Goland, 25 Oct 2004     Yuzo Fujishima, 26 Oct 2004     Eckenfels. Bernd, 26 Oct 2004     Yaron Y. Goland, 26 Oct 2004     Yuzo Fujishima, 27 Oct 2004     Yaron Y. Goland, 2 Nov 2004     Proposed resolution (Yaron Y. Goland, 2 Dec 2004)
Changes: 18 Oct 2004 - new issue;    18 Oct 2004 - fields: Links;    25 Oct 2004 - fields: Links;    26 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Links;    2 Nov 2004 - fields: Links;    10 Nov 2004 - fields: Status, Vote announcement;    11 Nov 2004 - fields: Status, Date accepted, Resolution, Vote announcement;    2 Dec 2004 - fields: Links, Status, Proposed resolution;    3 Dec 2004 - fields: Status


Issue 171: faultName should be optional for invoke fault handlers

Status: resolved
Date added: 18 Oct 2004
Categories: Syntax & semantics
Date submitted: 15 October 2004
Submitter: Yuzo Fujishima
Date accepted: 27 October 2004
Champion: Yuzo Fujishima <fujishima@bc.jp.nec.com>
Document: WSBPEL Working Draft, September 8, 2004
Description: In 6.2 and 11.3 of the specification, the faultName attribute of a catch element of an invoke element is shown to be mandatory.
     <catch faultName="qname" faultVariable="ncname"?
                              faultMessageType="qname"?>*
To be consistent with a fault handler defined for a process or a scope, this attribute should be optional.
Submitter's proposal:

In 6.2 and 11.3, replace

     faultName="qname"
with
     faultName="qname"?

Resolution: Proposed in Yuzo Fujishima, 7 Dec 2004, decided at Hawthorne f-t-f

In "6.2. The Structure of a Business Process" and "11.3. Invoking Web Service Operations",

Replace

  faultName="qname"
With
  faultName="qname"?

Links: Announcement, 18 Oct 2004     Proposed resolution (Yuzo Fujishima, 7 Dec 2004)
Changes: 18 Oct 2004 - new issue;    18 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Status, Date accepted;    7 Dec 2004 - fields: Links, Status, Proposed resolution;    15 Dec 2004 - fields: Status, Proposed resolution, Resolution

Issue 172: Clarification/correction of correlation sets example in sec. 10.2

Status: resolved
In spec: 25 Nov 04
Date added: 18 Oct 2004
Categories: Correlation
Date submitted: 18 October 2004
Submitter: Ugo Corda
Date accepted: 27 October 2004
Description: In the example, the AsynchPurchaseResponse <invoke> uses the correlation sets PurchaseOrder and Invoice, but neither correlation set has any connection with the message being sent by that particular <invoke>.
Resolution: Agreed at conf call, 27 October 2004

Passed to editing team to be fixed as a bug
Links: Announcement, 18 Oct 2004
Changes: 18 Oct 2004 - new issue;    18 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Status, Date accepted;    29 Oct 2004 - fields: Status, Resolution;    25 Nov 2004 - fields: In spec


Issue 173: Value of initiate attributes in Multiple Start Activities example

Status: resolved
In spec: 25 Nov 04
Date added: 20 Oct 2004
Categories: Examples
Date submitted: 20 October 2004
Submitter: Ugo Corda
Date accepted: 27 October 2004
Description: Value of initiate attributes in Multiple Start Activities example (sec. 16.3.2)

The first two receive's in the process (under the flow activity) have initiate="yes". It looks like it should be initiate="rendezvous" instead.
Resolution: Agreed at conf call, 27 October 2004

Passed to editing team to be fixed as a bug
Links: Announcement, 20 Oct 2004
Changes: 20 Oct 2004 - new issue;    21 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Status, Date accepted;    29 Oct 2004 - fields: Status, Resolution;    25 Nov 2004 - fields: In spec


Issue 174: Are multiple imports with the same namespace allowed?

Status: open
Date added: 23 Oct 2004
Categories: Related standards
Date submitted: 27 September 2004
Submitter: Jim Clune
Date accepted: 10 November 2004
Description: Is it legal to have a BPEL process with two BPEL import elements each pointing to WSDLs of the same namespace, but different locations? The Document Linking section of the spec does not explicitly disallow this. One might interpret this situation as legal, and one might further interpret references to WSDL elements within such a process as resolving so long as each element resolves to one of the imported WSDLs for that namespace.

The text should be clear.
Links: Announcement, 23 Oct 2004     Alex Yiu, 24 Oct 2004     Prasad Yendluri, 24 Oct 2004     Yaron Y. Goland, 25 Oct 2004     Prasad Yendluri, 25 Oct 2004     Danny van der Rijn, 25 Oct 2004     Prasad Yendluri, 25 Oct 2004     jim@parasoft.com, 26 Oct 2004     Prasad Yendluri, 26 Oct 2004     jim@parasoft.com, 26 Oct 2004     Prasad Yendluri, 26 Oct 2004
Changes: 23 Oct 2004 - new issue;    24 Oct 2004 - fields: Links;    25 Oct 2004 - fields: Links;    26 Oct 2004 - fields: Links;    27 Oct 2004 - fields: Links;    11 Nov 2004 - fields: Status, Date accepted


Issue 175: Supporting WSDL Overloading in BPEL

Status: resolved
In spec: 25 Nov 04
Date added: 27 Oct 2004
Categories: Syntax and validation
Date submitted: 26 October 2004
Submitter: Yaron Y. Goland
Date accepted: 10 November 2004
Description: WSDL 1.1 explicitly supports operation overloading (section 2.5) although WS-I BP 1.1 eventually banned it (R2304). But since BPEL doesn't restrict itself to just WS-I (Issue 72) we still have to deal with overloading.

The problem is that when executing a message operation like a receive just specifying the partnerLink, portType and operation is not enough to uniquely identify which operation is intended in an overloaded portType. Strictly speaking one also needs to specify both the name of the input and (if present) the output elements in order to uniquely identify an overloaded operation.

There are a number of consequences to this ambiguity:

Receive/Pick & Reply - It is impossible to know which overloaded operation one is waiting for.

Even using the variable type as a tie breaker isn't guaranteed to work since it is legal to have two input elements in two overloaded operations with different names but identical types. In the case of a one-way we might just fudge things and say that the receive/pick is able to wait for two or more operations using the same variable type simultaneously but in the case of request/reply we can be in big trouble since there is no way to statically know if the reply is correct. E.g. if two operations have the same name and same inputs but different outputs.

Just to make things even more fun one could have two identically named operations whose input and output elements have different names but identical types. In that case the BPEL variable typing will work but there is no way for the WSDL binding to know which of the overloaded operations was intended since BPEL doesn't communicate the input/output element names as part of the BPEL messaging operation.

Invoke - Same issues in reverse.
Submitter's proposal: I can see two ways to solve this issue. The one I prefer is that we just declare in the spec that BPEL doesn't support overloaded WSDLs and call it a day.

But another choice is to extend our messaging operations to optionally allow for the specification of the input/output element names (we would need both in the case of request/response operations).
Resolution: Agreed at conf call, 10 November 2004

A clarification will be added that BPEL must not process WSDL with a single port type and multiple operations of the same name. Final wording to be determined by the spec editing team.
Links: Announcement, 27 Oct 2004     Eckenfels. Bernd, 27 Oct 2004     Alex Yiu, 27 Oct 2004     Yuzo Fujishima, 3 Nov 2004
Changes: 27 Oct 2004 - new issue;    27 Oct 2004 - fields: Links;    28 Oct 2004 - fields: Links;    3 Nov 2004 - fields: Links;    11 Nov 2004 - fields: Status, Date accepted, Resolution;    25 Nov 2004 - fields: In spec


Issue 176: Removing Section 4

Status: resolved
In spec: 19 Nov 2004
Date added: 27 Oct 2004
Categories: Specification editing
Date submitted: 26 October 2004
Submitter: Yaron Y. Goland
Date accepted: 10 November 2004
Description: Section 4 of the specification defines some of the changes from BPEL 1.0 to BPEL 1.1. It is, however, no longer accurate since the TC has decided to supersede BPEL 1.1 with BPEL 2.0 which is substantially different.
Submitter's proposal: Minimally I think we need to get rid of section 4. Ideally we would put in the appendix a list of changes from BPEL 1.1 to 2.0 but I must admit that I wouldn't be willing to volunteer to do it and I don't like proposing things I wouldn't do myself.
Resolution: Agreed at conf call, 10 November 2004

Section 4 will be deleted Text will be deleted in the next editing, but the section may remain until final editing when cross references will be cleaned up.
Links: Announcement, 27 Oct 2004
Changes: 27 Oct 2004 - new issue;    28 Oct 2004 - fields: Links;    11 Nov 2004 - fields: Status, Date accepted, Resolution;    19 Nov 2004 - fields: In spec


Issue 177: Inconsistent optional/required nature of @Variable on onMessage, onEvent and Receive

Status: open
Date added: 28 Oct 2004
Categories: Syntax & semantics
Date submitted: 28 October 2004
Submitter: Prasad Yendluri
Date accepted: 10 November 2004
Document: WSBPEL Working Draft, September 8, 2004
Description: The optional or required nature of Variable attribute is inconsistent in the specification. On <receive> activity, onMessage clause of the <Pick> activity the @variable is optional. Where as on <onEvent> handler the @variable is required. Additionally per section 15.1 it is permissible in abstract processes to omit the variable reference attributes from the <invoke/>, <receive/>, and <reply/> activities. However for executable processes there is no specification on the optional or required nature of @variable. In the case of OnEvent handler which can have several simultaneous active instances, the @variable is defined to be of @messageType declared within an implicit scope associated with the event handler; upon receipt of the input message the event handler is required to assign the input message to the variable before proceeding to perform the event handler activity, which makes the @variable required. This inconsistency of optional and required nature of the @variable on different activities seems to be a source of confusion, that needs to be clarified in the specification.
Submitter's proposal: Consistently require the @variable on all these activities for executable processes, making it optional for abstract processes only.
Links: Announcement, 29 Oct 2004     Dieter Koenig1, 29 Oct 2004     Prasad Yendluri, 29 Oct 2004
Changes: 28 Oct 2004 - new issue;    31 Oct 2004 - fields: Links;    11 Nov 2004 - fields: Status, Date accepted

Issue 178: Correlation sets visible to an event handler

Status: resolved
In spec: 25 Nov 04
Date added: 2 Nov 2004
Categories: Correlation
Date submitted: 01 November 2004
Submitter: Yaron Y. Goland
Date accepted: 10 November 2004
Description: The text in section 13.5 does not seem to specify which correlation sets are visible to an onMessage handler inside of an event handler. Does an event handler only see correlation sets in the ancestor scopes or can it also see correlation sets defined in the scope it is defined on?
Submitter's proposal: I suspect the intention was that event handlers can see correlation sets both in the scope it is defined on and in the parent scopes but this needs to be made clear in the text.
Resolution: Agreed at conf call, 10 November 2004

A clarification will be added to say that all handlers associated with scope are lexically local to that scope.
Links: Announcement, 2 Nov 2004     Dieter Koenig1, 4 Nov 2004     Yaron Y. Goland, 9 Nov 2004     Yaron Y. Goland, 9 Nov 2004
Changes: 2 Nov 2004 - new issue;    2 Nov 2004 - fields: Links;    4 Nov 2004 - fields: Links;    10 Nov 2004 - fields: Links;    11 Nov 2004 - fields: Status, Date accepted, Resolution;    25 Nov 2004 - fields: In spec


Issue 179: Type Compatibility in Assignment of EPRs

Status: resolved
In spec: No change
Date added: 12 Nov 2004
Categories: Data handling
Date submitted: 12 November 2004
Submitter: Dieter Koenig
Document: Specification working draft, Section 9.3.1, "Type Compatibility in Assignment".
Description: In Section 9.3.1, the second list bullet reads:
The from-spec is a variable of a WSDL message type and the to-spec is not, or vice versa. This is not legal because parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly.

One could interpret this as if an assignment from a variable of a WSDL message type to a partner link is not allowed because the partner link is not itself a variable of a WSDL message type. Likewise for assignments in the reverse direction.
Submitter's proposal: Clarify that an assignment to/from a partner link IS allowed when the from/to spec is a variable of a WSDL message type.

The endpoint reference is in a message part of this WSDL message, either the complete part or an element contained in the part.
Resolution: Accepted and immediately closed on conf call 24 Nov 2004

Closed as duplicate (or will be treated as part of) issue 51 : Section 9.3.1 & Schema Validation
Links: Announcement, 12 Nov 2004     Yaron Y. Goland, 15 Nov 2004     Prasad Yendluri, 23 Nov 2004     Dieter Koenig1, 24 Nov 2004
Changes: 12 Nov 2004 - new issue;    17 Nov 2004 - fields: Links;    24 Nov 2004 - fields: Links, Status, Resolution, In spec


Issue 180: Clarification of WSDL fault declarations and Reply in BPEL

Status: open
Date added: 4 Dec 2004
Categories: Related Standards, Fault handling
Date submitted: 02 December 2004
Submitter: Yaron Y. Goland
Date accepted: 8 Dec 2004
Description: Section 11.3 states that WSDL faults in BPEL are identified just with the portType's namespace and the fault's local name even though this does not match the WSDL 1.1 fault model which uniquely identifies faults using a combination of the portType name, operation name and fault name.

Imagine however the following WSDL whose target namespace prefix is "foo" :

portType name="aPort"
    operation name="o1"
       ...
       fault name="aFault" ...
          ...
    operation name="o2"
       ...
       fault name="aFault" ...
          ...
    operation name="o3"
       ...
       fault name="aNewFault" ...
          ...

Now imagine the following BPEL fragment:

    ...
    reply partnerLink="..." portType="foo:aPort" operation="o1"/
          variable="..." faultName="foo:aFault"
    ...
    reply partnerLink="..." portType="foo:aPort" operation="o1"/
          variable="..." faultName="foo:aNewFault"

Which of the replies, if any, are legal?

Is the language in section 11.3 only meant to apply when receiving a fault? If so then the first reply is legal (and unambiguous) and the second is not.

If, on the other hand, the language in section 11.3 is meant to apply both to receiving and sending faults then the first reply is illegal but the second is probably legal.

The first reply is illegal because the situation is ambiguous. If 11.3 applies then BPEL overrides the WSDL semantics and requires that faults be identified exclusively by portType name and fault name. In that case having "aFault" defined twice in the same portType (even if the message types were different) is an error that should be caught by static analysis and thus require the process to be rejected.

The second reply is legal because although "aNewFault" is not defined in operation o1 its fault name and portType combination are unique and so we can resolve the reference even though it isn't in the same operation and thus, strictly speaking, isn't legal in canonical WSDL.
Submitter's proposal: I propose that the language in section 11.3 only apply to receiving faults on invokes and that we make this limitation explicit in sections 11.3 and 11.4 so there is no confusion. When sending a fault using a reply we should follow the normal WSDL rules and identify the fault using the unique combination of portType, operation name and fault name. This would mean that in the previous example the WSDL would be accepted and the first reply would be legal and the second would not.
Links: Announcement, 4 Dec 2004
Changes: 4 Dec 2004 - new issue;    5 Dec 2004 - fields: Links;    8 Dec 2004 - fields: Status, Date accepted


Issue 181: uninitializedVariable cleanup

Status: open
Date added: 10 Dec 2004
Categories: Syntax and validation
Date submitted: 10 December 2004
Submitter: Yaron Y. Goland
Date accepted: 14 Dec 2004
Description: Section 14.2 currently states "An attempt during process execution to use any part of a variable before it is initialized MUST result in the standard bpws:uninitializedVariable fault."

Appendix 1 in table A.1 in the row marked uninitializedVariable currently states "Thrown when there is an attempt to access the value of an uninitialized part in a message variable."

In both cases there is a presumption that variables can only be of WSDL message type.

Thanks to Ron Ten-Hove for finding this problem.
Submitter's proposal: Change the text in 14.2 to read: "An attempt during process execution to use a variable or in the case of a message type variable a part of a variable before it is initialized MUST result in the standard bpws:uninitializedVariable fault."

Change the text in table A.1 to read: "Thrown when there is an attempt to access the value of an uninitialized variable or in the case of a message type variable one of its uninitialized parts."
Links: Announcement, 11 Dec 2004
Changes: 10 Dec 2004 - new issue;    11 Dec 2004 - fields: Links;    14 Dec 2004 - fields: Status, Date accepted


Issue 182: Can <catch faultName="qname"> catch a fault with a data body?

Status: received
Date added: 6 Jan 2005
Categories: Fault handling
Date submitted: 15 December 2004
Submitter: Alex Yiu
Champion: <a href="mailto:alex.yiu@oracle.com">Alex Yiu</a>
Document: BPEL specification
Description:

According to our current fault matching rules IF a fault has a body THEN it can only be three ways - by a catch that specifies the name and body, by a catch that just specifies the body or by catch all. But notice what can't catch it, a catch that just catches on the name.

That means, if someone needs to add a data body to the fault later (to add optional interesting data) then all existing catches will be broken.

Proposed Solution:

It would be better to allow <catch faultName="qname"> to catch with fault data body as well.

Changes: 6 Jan 2005 - new issue


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