1. Report from the Abstract Process Clarification Sub- Committee Monday June 21, 2004

2. History of Abstract BPEL Sub-Group BPEL spec was judged to be unclear as to what exactly BPEL Abstract is. Expressed interest in gaining a better understanding of Abstract BPEL to TC Chairs. Asked to coordinate efforts of others in the BPEL TC in order to get an overall better understanding of ABSTRAC BPEL.

3. Official/Unofficial Charter Derive a candidate definition for Abstract BPEL Derive a candidate list of requirements for Abstract BPEL Determine a candidate set of use cases from which the abstract BPEL requirements can be derived. Act as a focal point wherein Abstract BPEL issues can be discussed and clarified for presentation to the entire TC. Update BPEL Spec with improved description of Abstract BPEL.

4. Short Term Goal(s) Have something ready to be presented at the face-to-face in San Francisco. Be better able to discuss the Abstract BPEL issues at the San Francisco face-to-face.

5. Logistics Meet weekly on Friday from 11:00 AM EDT to 12:00PM EDT via a Unisys Provided phone link. Phil Rossomando acts as facilitator, meeting coordinator and scribe. Secessions are taped and transcribed to insure accuracy of information capture Transcribed minutes posted on an OASIS provided sub-group bulletin board. Any papers produced by the group or members thereof are posted on the sub-group site. Sub-group E-mail distribution list established.

6. Issues Discovered Discovered others in BPEL TC equally confused as to what Abstract BPEL is and should be used for. Without good understanding of what Abstract BPEL is, members were having difficulty deciding how to vote on Abstract BPEL issues. Some felt that it was up to the original authors to define Abstract BPEL and until they did so, the rest of us could not make valid decisions as to how to use it. Discussions tended to run in circles (need requirements but can’t till get use case, need use cases but can’t till get requirements…)

7. Issues Discovered Continued We need a glossary of terms so that we can understand each other better (e.g. what is a protocol?). Realized that Abstract BPEL may be different depending on the audience: If used as a tool to show a customer you understand her business. If used as a tool to tell a potential partner how to engage in a business activity with you. If used to communicate between business systems developers.

8. Progress To Date Decided to proceed without formal definition of BPEL being provided by original authors. Discussions have been held wherein the purposes of Abstract BPEL have been discussed in detail. Two Abstract BPEL use cases were presented to the group. Three more have just been added. Issues 99 and 107 were discussed in detail and a much better understanding has been arrived at by the participants. Individuals have provided suggestions for Abstract BPEL requirements and use cases.

9. Progress To Date Continued A first cut straw-man Abstract BPEL description has been produced based on input form the participants drawn from the meeting minutes, published papers and email contributions. A first cut straw-man set of use cases and Abstract BPEL requirements have been produced. An on-line dialogue has been started.

10. Follow-up Action Items The straw-man items now available must be gone through, and each item clarified, prioritized and voted on. A glossary must be written. Based on improved understanding derived from above exercises, the abstract BPEL outstanding issues must be resolved. The Spec needs to be updated. A target time-line needs to be produced.

11. Suggested F2F Objectives (Satish Proposed). What use cases do we take as essential requirements for partially specified processes? My suggestion is that we take external or public view of behavior of a single process (participant) as the only canonical and essential use case. 2. What does "partial" mean? In other words, which syntactic elements are allowed to be left out and which other rules relaxed? Are there syntactic elements that are forbidden in abstract processes? This will clearly be dictated by 1. 3. What is the *meaning* of conformance between an abstract process as a public view and the corresponding private executable process? This is a precise "mathematical" relationship that needs to be well-defined in all cases but does *not* need to be algorithmically decidable. This cannot be addressed without resolving 2. 4. What is the syntactic device for omitted elements in partially specified processes? For instance, simple textual omission vs explicit marking. I believe this will be dictated by the answer to 3.