1. BPEL F2F Jan 10 – 12, 2006

2. Proposed agenda Jan 10-12 Administrative start up –attendance, quorum, minute takers –Review/accept minutes from previous meeting(s) - Dec. 7, 14 Review and approve latest draft of spec as current committee draft Outstanding proposals to vote –229 –82.1 –239 Review all open issues and work on proposals to close Primer status Note: we will take an agenda checkpoint every two hours to adjust topics and update roll call

3. Summary Jan 10 Minutes from previous meetings accepted 229 – naming issue will be dealt with in 217. Chris will send an updated proposal with new wording as discussed in the meeting for voting wed or thurs. Review of committee draft – vote deferred to next meeting/call to give people more time to review. 239 – proposal from Alexandre accepted. 120, 120.1 – closed with motion to add clarification: if there is no explicit correlation set used in an inbound message activity (initial or non-initial) an implicit implementation specific correlation mechanism MAY be used. Diane to call this to Danny’s attention since he was interested in these issues and may want to make a further change. 162 – the wording that was added to the spec missed a parenthetical phrase in the motion. This should be added back in. Peter will move it back to the editing work queue and Prasad will fix it. 120.2 – closed with no change to the spec given the resolution to 123 and a new issue opened to deal with the onevent binding (241) 144 – will be dealt with after the restructure 184 – Passed proposal to close 184 with addition of a clarification that the examples in the spec are not in general fully specified unless otherwise noted. This should be stated at the start of the specification and in section 16. Typos identified will be corrected. If any member identified an example that they believe needs to be further specified they may open an issue and provide the resolution to have the example updated. The group working on the primer may wish to include more examples with greater degree of specification. 207/216/226 – reviewed Dieter’s proposal. He will provide an update and make a motion with changes as discussed. 217 – passed proposal: Rename to. Remove scope attribute from "compensate" and can only mean default compensation of child scopes. The term "compensate activities" refers to both kinds of compensate behavior. We need to go through spec to disambiguate the occurrences of "compensate". Clarification of the meaning of these terms will be added. 218 – there has been some work on this among a few members. After discussion, the sense in the room was: isolation semantics appliy to the epr part of the partner links. Isolation semantics do not apply to message exchange part of partnerlink. Correlation sets are mutable once (write once) therefore isolation semantics do not apply. We should close 218 by extending the isloation semantics to include epr part of partnerlink. Alex to write up proposal

4. Proposed agenda Jan 11 Remaining proposals: 82.1 Updated proposals if available for –229 –207/216/226 –218 Continue review of all open issues and work on proposals to close Primer status Schedule Note: we will take an agenda checkpoint every two hours to adjust topics and update roll call

5. Summary Jan 11 218 – Alex to provide an updated proposal 229 – closed with resolution to change wording in 13.3.3 to read: User-defined fault handlers, compensation handlers, or termination handlers may use to compensate a specific child scope and/or to compensate all child scopes in default order. Any repeated attempt to compensate child scopes MUST be ignored. When user-defined fault handlers, compensation handlers, or termination handlers are executed an implementation MUST not invoke child scope compensation unless the compensate activities are used. 191 – close with no change and the following explanation: the example in the original write up of the issue is invalid and that is stated in 11.4. Within while loop it is invalid to have createinstance=yes. The example in the Mar 15 email on this thread is valid, semantics are clear and it is a legitimate usage, See section 10.2. 234 – closed with resolution: –1.. In 12.6. Flow, replace:these lines: a link that crosses a fault-handler boundary MUST be outbound. With these: * a link that crosses a fault-handler or a termination handler boundary MUST be outbound. –2. insure that DPE section in spec takes care of links leaving a termination handler (and fault handler if not already covered) just like if activity and fault handler. –3. The last paragraph before 12.6.1 where a fault-handler is mentioned, the words "or a termination handler" should be added. –4. in the same paragraph add a sentance: In the case of termination handler, the scope of target activity MUST not be the parent scope of the scope associated with the termination handler. 221 – Directional proposal adopted, Dieter volunteered to work on wording. The missingReply standard fault is useful today on the process level, and even more if it can be detected on the scope level. Use this approach: missingReply can be detected during termination of a scope in which the used partner link or message exchange is defined: –==> (1) If the scope's contained activity and the scope's event handlers have completed, a check for missing replies MUST be made. If then a missingReply is thrown - this is still inside of the scope, so the scope itself can catch it –==> (2) If the scope's fault handler (for a different fault), has completed then a check for missing replies MUST be made. If then a missingReply is thrown it goes to the parent scope –==> (3) If the scope's fault handler faulted itself then the parent scope can catch that other fault (missingReply is lost) - note that this is just another case where multiple faults have been detected and only one gets propagated. –==> (4) If the scope's termination handler is executed then no fault is thrown (missingReply is lost like any other fault in the termination handler )

6. Summary Jan 11 cont’d 223 – closed with resolution: 123 Currently says: in section 11.4 "An open IMA describes the state of a Web service operation from the point that a request/response IMA starts execution until an associated reply begins execution." This should be changed to: "An open IMA describes the state of a Web service operation from the point that a request/response IMA starts execution until an associated reply activity completes successfully. This implies that if a reply activity faults, the IMA is still open and another reply activity MAY be attempted, for example from a fault handler." 82.1 – Directional proposal adopted – see Vinky’s email with updated proposal: http://lists.oasis- open.org/archives/wsbpel/200601/msg00043.html 235 – Closed with resolution: Change the paragraph from the Issue 88 resolution from - namespace. The namespace attribute specifies an absolute URI that identifies the imported definitions. This attribute is optional. An import element without a namespace attribute indicates that external definitions are in use which are not namespace qualified. –to -namespace. The namespace attribute specifies an absolute URI that identifies the imported definitions. This attribute is optional. An import element without a namespace attribute indicates that external definitions are in use which are not namespace qualified. The namespace http://www.w3.org/2001/XMLSchema is imported implicitly. Note, however, that there is no implicit XML Namespace prefix defined for http://www.w3.org/2001/XMLSchema. 241 – general agreement that the resolution rules for resources used by onEvent: – * partnerLink: resolved to local scope first and then ancestor scope – * correlation: same as partnerlink – * variables are always resolved to associated scope only – * messageExchange: same as partnerLink Spec text required. Collapse the syntactic element with the syntactic element will also be considered.

7. Proposed agenda Jan 12 Schedule Primer status Updated proposals if available for –207/216/226 –218 –241 –Any other issues we should revisit Note: we will take an agenda checkpoint every two hours to adjust topics and update roll call

8. Summary Jan 12 Schedule for OASIS standard adopted as intent of TC. Transcription of what was on the board is on the next page. Next F2F: Mar 20-24, Mon noon to Fri noon location tbd. Purpose will be to walk through spec in preparation for public review Following F2F: ballot to be posted to choose between weeks of July 17, 24 or 31. Will be usual 3 day meeting Primer status: group has outline available and continues to meet. Issue 207, 216, 226: Dieter’s updated proposal passed. Issue 207.1 proposed by Alex and opened by TC. Issue 241: Sense of TC: do not collapse the and syntactic elements. The reason to collapse would be to get more backward compatibility - but if you do that, where you declare the correlation set will not be consistent with the normal scope syntax. For the parallel foreach case we are not going to collapse them so for syntax consistency it is better to not collapse. Issue 240: closed with resolution: If we have a glossary and in the text of the document with appropriate definition on its first usage the possible things that a variable can be declared as: type, element, messageType, may be grouped together with the term “BPEL Variable Type” at the editors’ discretion.

9. Schedule adopted Finish issues 2-4 weeks Jan 31 Incorporate resolutions in draft 2-4 weeks Mar 1 Approve committee draft (inclusive of all normative changes from all issues) 2 weeks Mar 15 Face to face meeting to start editing cycle (end to end consistency, restructure) 5 days Mar 20-24 Editing complete for public review candidate 3 weeks (Public review candidate sent for TC review) April 15 Approve public review candidate 2 weeks May 1 Public review 60 days June 30 –If appropriate continue editing for improved readability –Start review and work on public comments as they are received Face to face meeting to review/address public comments Week of July 17, 24 or 31 Prepare updated public review candidate 2 weeks Aug 1 Second public review cycle 15 days Aug 15 Committee spec Aug 30 OASIS Standard Oct. 15 Note dates are approximations some of which depend on OASIS process steps or staff actions.