Minutes W3C WS Choreography WG con call held on 24th June 2003, 1pm PDT.


1. Role Call

2. Confirm scribe

3. Approve minute

4. Action Item Review

5. Informal reportage on the last face2face

Technical harvesting track 2

. Harvesting the +ves and –ves from WSCI, BPEL, DAML-S, BPML, BPSS

Technical harvesting track 3

. Harvesting the +ves and –ves from BurdettML, Event Calculus and the Pi-Calculus

Issue tracking

6. Tracking items (a section designed to ensure that longer running items and issues raised are properly tracked)

Mission Statement (progress)

Requirements (progress)

General technical issues

7. What is the value of a choreography language over and above WS-BPELabstract processes for users? (Discuss)

8. Threads (on the archive not covered elsewhere in the agenda)

. Choreography protocol

. Liason Statement

9. AOB.

Role Call:


 Martin Chapman


Steve Ross-Talbot




W3C Staff Contacts


Yves Lafon









Yaron Goland

BEA Systems

Mayilraj Krishnan

Cisco Systems Inc

David Burdett

Commerce One

Paul Lipton

Computer Associates

Fred Cummins


Francis McCabe

Fujitsu Ltd

Yoko Seki

Hitachi, Ltd.

Yutaka Kudou

Hitachi, Ltd.

Greg Ritzinger


Nickolas Kavantzas

Oracle Corporation

Ugo Corda

SeeBeyond Technology Corporation

Michael Champion

Software AG

Monica Martin

Sun Microsystems, Inc.

Carol McDonald

Sun Microsystems, Inc.

Jon Dart

TIBCO Software

Leonard Greski

W. W. Grainger, Inc.

Daniel Austin

W. W. Grainger, Inc.

Ed Peters

webMethods, Inc.



Raw IRC log at: http://www.w3.org/2003/06/24-ws-chor-irc


Appointment of scribe:


Jon Dart, TIbco, kindly volunteered to scribe for the meeting.


Previous scribes (in order):  David Burdett, Ed Peters, Greg Ritzinger, Monica Martin, Len Greski, Jean-Jacques Dubray, Monica Martin, Mayilraj Krishnan, Francis McCabe, Michael Champion, Abbie Barbir, David Burdett, Jon Dart, Carol McDonald, Yaron Goland, Leonard Greski, Ed Peters, Greg Ritzinger, Daniel Austin, Peter Furniss, Jim Hendler




Minutes Approval


10th June minutes: http://lists.w3.org/Archives/Member/member-wschor/2003Jun/att-0019/20030610-0.html


SRT: any objections to minutes from last cc?

minutes approved


Action Item Review

[note actions need to be updated with new actions from F2F]


ACTION: Carol to look into WSCI summary.

SRT: WSCI Summary from Carol

Carol: have sent slides


ACTION: SRT to capture reqs from minutes.

SRT: action on me to capture requirements .. superceded by agenda item


ACTION: All: alternate formal models other than the pi-calculus. Agenda item for next F2F – proposal from FM Event Calculus)

SRT: alternate formal models .. done

SRT: Frank McCabe gave an intro to event calculus


ACTION: DA will do the wordsmith, summarize and put together revised mission statement. Once again it is not final.

DA: There has been a lot of back and forth. Want to reframe statement made to BPEL group. Suggest add to agenda for next week

DA: Need to incorporate text from statement made to BPEL group into mission statement


ACTION: SRT to extract summaries of harvested specs (wsci, bpel).

SRT: superceded by agenda item from F2F



ACTION: DA will own the privacy discussion thread and summarise the requirements that ensue.


DA: is in progress


ACTION: FMC to send in URL for WSA privacy document

Frank: sent URI during meeting

SRT: mark as done, will try to find it

need to check F2F minutes


ACTION: MC to add FMC to F2F agenda for event calculus presentation

SRT: MC, add Frank to agenda .. done


ACTION: SRT to write a straw man proposal on BPEL liaison.

SRT: action on SRT to create strawman for BPEL liaison .. done






 Informal reportage on the last face2face


SRT: informal report on F2F .. maybe those who were there can give impressions

SRT: There were 3 task forces set off at F2F

SRT: one is to look at req document

SRT: deadline to get out for public review asap

SRT: Then a task force to harvest + and - from existing inputs (BPEL, WSCI, BPSS, DAML-S)

SRT: Then task force #3 is to harvest from David Burdett's submission and at + and - in event calculus and pi calculus

SRT: those of you not currently involved in these task forces, look for leaders of the task forces to get involved

YG: BPSS not mentioned?

YG: (in track 3)

SRT: It is somewhat arbitrary.

SRT: BPSS nearly was in track #3. JJ did give a presentation on BPSS. Because it was already an input to the group, I put it in task force #2

SRT: Harvesting activity should be as thorough as possible. We should not look only slightly at things

SRT: any comments from participants at F2F?

JD: mission statement produced at meeting was a good first cut

YG: was a bit surprised at differences from what was discussed on the list

JD: need to reconcile


NEW ACTION: reconcile mission statements


MC: some items such as machine readable are implicit IMO

MC: seemed obvious at the meeting

YG: statement should tell what we do and what we don't do

YG: F2F version was more open-ended

MC: this was talked about. Somebody said we shouldn't include things we won't do.. the list is endless

DA: there is scope for creative ambiguity. We don't know what will happen in future. We may need room to manouver.

YG: mission statement can be changed

Frank: the most substantive difference between YG and co's version and F2F version is service composition and semantics. I see these as serious issues we need to address.

I agree with FM on this point

Frank: You can do choreography w/o composition or semantics (semantics doesn't mean doing WS semantics, but to relate semantics to services)

Frank: we did have some difficulty capturing that properly

Frank: Need to get hold of issue of WS composition

YG: need to get specific

YG: need to get agreement on terms

Frank: My $0.02: service composition means composing 2 or more services together to have a new service.

Frank: Does that new service require any programming? If it does, IMO it is not really WS composition

Frank: Yaron, you have wanted to exclude executable languages. I also think we don't want to do composition involving programming.

YG: I don't understand what WS composition outside programming code means

SRT: let's try to resolve this. Get next level down explanation of what we mean.

SRT: Need to keep mission statement as 1 para but also have definitions of what we mean, separate from the mission statement

MC: I think we could just work on shoring up the wording .. is good as is

Carol: could use glossary to clarify what we mean

SRT: good idea

Monica: service semantics may not be in there, but there are defns of compositions

Monica: there is >1 defn of composition.

Monica: Can start discussion on it

SRT: should have Jim Hendler in discussion. He certainly does transparent composition



SRT: Any other items?

JD: BPEL liaison?

SRT: I did see Diane's report on OASIS mailing list

Monica: I haven't read her comments.

Monica: They have formed a use case sub-committee. I'm not sure how this works, but it is a good point of discussion on how we might interact.

Monica: Should there be a liaison, we need to have it done formally, and soon

SRT: Diane sent to ws-bpel-liaisions

SRT: Diane said our WG could involve interactions at a higher level, may overlap BPEL process support. Avoiding overlap entirely may not be possible. Could possibly share use cases.

SRT: could identify common requirements, collaborate on presentations, joint meetings

SRT: WS-Chor focuses on WSDL 1.2, WS-BPEL on WSDL 1.1

SRT: working together may involve process issues

SRT: it seems there's no policy for this on either side

SRT: action for BPEL TC is to confirm liaison persons

SRT: We talked at the meeting about the need to cooperate. We set out the area we are in, and asked Diane to clarify what WS-BPEL is doing, in the same way we clarified our goals in the mission statement.

SRT: They are aware of what we're not likely to do - the execution stuff

SRT: We need to feel comfortable with the WS-BPEL group, by having same degree of information about them

Frank: the BPEL working group has spent 0 time considering WS-Choreography.

Frank: Diane said very clearly that their focus is working on current BPEL spec. They will not go beyond it, in any significant way.

Greg: today I asked Diane to take me off the liaision position, for various reasons.

SRT: Know who might replace you?

Greg: no


Martin C: have to go



SRT: apologies for not having F2F minutes yet.. will have out asap


SRT: one other item from F2F: YG asked for this: issue tracking


SRT: Martin gave demo on BugZilla. http://www.w3c.org/Bugs


SRT: This is where issues should be lodged (and bugs)

YG: but how?

YG: should discussions go in BugZilla?

DA: I would propose that conversation go on mailing list, referencing bugs by name or number.

DA: bug entries should contain minimal info needed to identify issue/bug

YG: do I need to add requirements to BugZilla?

SRT: it would be nice. The requirements editors would be happy.

SRT: we may get your requirements in before you do

DA: We need requirements by July 1, for july 8 heartbeat deadline.

JD: need dynamic participation use case

JD: will attempt to dig up or write one

MChapman: on the use of bugzilla, i think discussions should carry on in email.

MChapman: the issue owner is resonsible for summarising and referencing relevent emails in bugzilla

SRT: Ed Peters, DA, and myself are working on requirements

SRT: general technical issues on agenda .. not sure what this is.

SRT: item #7 was raised by at least 2 people: what is it all for? What is the value in doing choreography?

SRT: Came from Tom Carroll and Paul Lipton

PL: We need to codify business and technical benefits

SRT: I know Yaron's use cases discuss the benefits in narrative form

PL: This is more general: it is more like the 1-page executive summary value proposition

SRT: there was a discussion at the beginning of the call, saying people don't really know about WS-Chor and what it is for.

JD: This should fall out of the use cases

DA: IMO we have user scenarios, not use cases. We have higher-level objects called user scenarios, need to be broken down into use cases

PL: need to show how services are built

Frank: focus has been on how services interoperate. One of the focuses of WSA is to show how all the pieces fit together. Need to understand how messages are structured, security, etc.

Frank: we are focusing on interoperability at message sequence level, between services

PL: Will you show people the use cases, people outside the group

JD: We are building a next level of metadata, above WSDL.

YG: Every customer I have who has built a non-trivial workflow winds up drawing a graph. I want to make this easier.

YG: These are detailed message-exchange charts. With a complex exchange, you need s/w and tools to model this.

YG: Need to be able to use this for validation so you can verify that your s/w does what it claims

YG: BPEL takes a process-centric view. This is not how our customers work.

DA: isn't notation out of scope?

YG: Don't need UML, etc. Need the underlying meta-model. Our company has ideas about what UI should look like. Too early for a standard there. But if you go to the underlying concepts, it is just a directed graph. Need a standard for this model, this is the point of exchange.

DA: Agree but your idea about validation indicates that we need to spend time and effort ..

DA: .. developing a formalism to enable us to do that. If that is necessary need to put work into it now. May take us towards Turing completeness.

YG: The only validation I am looking for is wrt ordering of messages

YG: It is what we call a language acceptor

YG: I only want to define the allowable set of messages between participants, as an ordered set, but allowing parallelism. No need for Turning completeness

DA: Another issue is side effect issue, this is what led me to mention Turning completeness. May need to validate there are no side effects.

YG: Don't understand "side effect" in this context

DA: Choreographies could have effects different from individual web services

DA: I don't think we disagree. We agree but not totally on the scope.

SRT: validation was discussed at the F2F. We need to fully understand what we mean by validation - is static or dynamic, and how wide it can be.

SRT: Can't answer this right now

JD: YG, how close is DB's proposal?

YG: I had some issues re licensing.

YG: I am very concerned about reading spec when IP not clear

SRT: can someone summarize the situation?

LG: What we agreed to at the F2F was that all participants would abide by W3C's IP requirements.

LG: Anything brought into group, unless identified as someone's IP, is available for the group to use

SRT: An email was sent, Yves felt this was acceptable

YG: Are they asking for an exception or is it RF, under the policy?

YG: As long as there is no request for exceptions, then we're done

SRT: My understanding is that is now the case. The words being used were, if the group decides to accept it, then IP rights would not be asserted. Then we understood that if we agreed to consider it, then we "accepted" it and it was RF


NEW ACTION: action on DB to come back with definitive email re: IP position on burdettML


YG: As soon as that happens, I will be happy to review it

Frank: DB was saying he wanted to submit it to the group. There was an issue with formal submission taking a lot of effort

YG: It is not being submitted as a note

YG: Yves, is there a formal process for submission to the group?

Yves: If the spec submitted has no IP claims, then the WG can just use it, no problem.

Yves: We need to verify the intent behind it.


SRT: continue with value proposition discussion?

DA: wanted to talk about validation?

SRT: I wanted to go back to YG's comment about his customers. If all this stuff is done, and it does what you want, then presumably BEA as a vendor will be able to make better tools

YG: That is the goal

SRT: One of these tools would be a validator..

YG: Yes. Two tools at least: one is for design. People tend to start with the circles and lines, then they want to be able to import that into their programming tools.

YG: Want to be able to say "I am implementing this role within the defintion" and have tool fill in framework

YG: May want to put in front of their system a validator, so they can see if message sequence follows chor.

SRT: was discussed at F2F

JD: There are 2 possible ways to verify choreography message sequence. One is to have context travel with message - which role it comes from, what state it is in or expects to be in. Another method was to have a validating wrapper, as YG suggested.

SRT: Ed, does this interest WebMethods?

Ed: we think this will be ultimately be useful. Something that focuses on validation would be especially useful.

SRT: Carol?

Carol: +1

SRT: To summarize, one of the benefits at the IT level is that I can deliver applications faster and more accurately. It has a continuing benefit in increasing the real-time robustness of communication, through validation.

YG: it is faster and easier to design & get agreement with partners

DA: <rant> There is a distinction between making languages validatable, and having a means to perform the validation. I want to do the former, not develop a validation mechanism</rant>


DA: Getting into the validation business is a big deal

arkin_:+1 as well

YG: I want this group to build a structure I can build validation around

DA: There is a process in pi-calculus for validation

DA: bisimulation is one

SRT: There are other concepts

YG: bisimulation is undecidable, in the general case

SRT: it may be weak/open bisimulation, something like that

DA: Would this allow us to do what YG suggested, re validation?

SRT: it would do it statically

SRT: I am not sure about the computational complexity

YG: it is a fundamentally different model. Bisimulation matches executable codes - do they do the same thing? Not practical in real world. I am talking about observation of real-time behavior.

SRT: A bisimulation process is like an experiment. You observe what the sequences of messages are. But that assumes you can press any button, in any order, and do it statically.

SRT: Yes you can do this statically, but it is impossible in the general case.

SRT: If the model for execution is the same as that for choreography, can do this, but we as a group may not adopt that restriction

SRT: What YG suggests is done at runtime. Probably a good 80/20 solution.

DA: I don't want to see us coming up with a post-validation info set or something like that. Want to be constrained about what kind of validation we are doing.

SRT: We must be very sure about what kind of validation we want to do. If want to do something different from Yaron's suggestion, may need to get expert advice.

Frank: bisimulation is undecidable, it's obvious. Yaron's tool is a debugging tool. Very useful for that.

Frank: Another business case is documentation. When you do construct business systems, you need to document them.

YG: That's what I said, design comes first, debugging later.

YG: add to agenda, relation to BPSS




Frank: how will task forces operate?


SRT: add to agenda for next week


NEW ACTION: Task force operation on next weeks agenda



DA: reminder from editor: use cases/requirements by July 1




Summary of New Action Points


            NEW ACTION: reconcile mission statements

NEW ACTION: action on DB to come back with definitive email re: IP position on burdettML

NEW ACTION: Task force operation on next weeks agenda