Minutes of the OASIS BPEL TC Call, 1/7/2004

(by Paco Curbera and Frank Leymann, IBM)

1. Meetings of the f2f have been accepted

2. Agenda has been accepted

3. Liaison: No special issues

4. Implementation subgroup:

a. First meeting next week

b. How should participate in that subgroup? Tool vendors have a role to play.

c. Unisys wants to become member based on an evaluation of four tool vendors

d. Unisys will submit a list of "observations" originating from this evaluation likely requiring clarifications of the specs.

5. Issues coordination - how to speed up processing them?

a. Charter set timeframe for a committee draft within 9 months; likely not achievable, but mid of 2004 seems realistic.

b. Satish hopes to make progress at next f2f, especially having corrections and clarifications added.

c. Set a revised time table for publishing the committee draft and, thus, for resolving issues.

d. Start proposing issues that are no longer relevant: Many issues might have gone away in the meantime

6. Vote on issue #13

a. Paco reviewed proposal how to resolve the issue

b. Discussion on the proposal: Declaring query language at the condition level seems to be too fine grained; Satish argues that processors will have a hard time figuring out what languages need to be supported for a specific process. A minimum set of languages are needed to ensure portability, and make sure that people understand that extensions break portability;

c. Problem of jeopardizing portability does exist already today, thus split this generic problem from issue #13.

d. Yaron suggests there are two additional issues, separate from issues 13: what to do when languages/extensions are not recognized, and the need for upfront declaration of query languages and other extensions used. Suggests that we vote issue 13 independently of these other problems. Satish, Danny, Paco and others agree.

e. Jeff states that he’s got concerns from his team regarding issues 13, though he is now unable to find the mail where they were articulated.

f. It is agreed to delay the vote until next meeting so that Oracle’s concerns can be discussed.

7. Next face to face scheduling.

a. SAP has offered to host it in Waldorff, near Heidelberg. Already have room for 20 people for 2 days. Would like to get a head count of who intends to attend.

b. Diane: last consensus date (as per last f2f discussion) was 3/1; start at 9:30, adjourn 1-2pm next day. Was not voted though. Proposal to vote the above is approved. Ballot will be posted asking for confirmation of attendance, and will stay open for several weeks to allow for travel approval to be obtained.

8. Discussion of Choreology’s proposal to move forward on issues 53-59 and 30 (support for coordination protocols in BPEL.)

a. Alistair motivates the proposal: the idea is to get the TC to make a decision on the direction in which it intends to move in this area. The motion proposes that BPEL recognize initiation and completion signals of coordination protocols without necessarily endorsing a specific protocol; it only talks about well understood concepts that are common to all proposals.

b. Satish reiterates his position, presented at the last f2f, that those signals are very often application messages; this model allows simple and also more complex coordination patterns to be built. This is not recognized by the proposal. Notes that it does not seem wise to endorse one particular protocol, but that the motion is not specific enough to work. Yaron agrees and suggests we wait for tx protocols to be completed before moving in this direction.

c. Alistair reminds that the motion is not intended to be complete, just indicate direction, but that enough details to work it out in detail in Choreology’s original proposal.

d. Satish will make sure his presentation is posted. Bob reminds that his presentation on the same subject is already posted.

9. Proposal for separate schemas for abstract and executable processes.

a. Idea is favored but there are questions regarding how difficult it is to achieve in the Schema language.

b. One option is to have two separate schemas, another is to have a common core schema and extensions for executable and abstract processes.

c. A second problem is whether abstract and executable processes schema components will live in the same or separate namespaces. In the first case this would probably require different top elements used to represent each kind of process. Thus, a processor would use either the namespace or the element name to distinguish between the two types of process.

d. It is agreed that more discussion is required and should continue on e-mail so that the proposal can be voted in the next call.

10. Adjourn.