Minutes W3C WS Choreography Face to Face Meeting 15 – 17th September 2003, Seattle, USA



Chair’s Summary

The W3C Web Services Choreography working group met in Seattle, hosted

at Attachmate, between the 15th and 17th September. About 20 people

attended the meeting. Much was achieved at the meeting. We have come

out of a period of divergence and are into a period of convergence.


A divergent period in which use cases were gathered and many

discussions occurred has resulted in the publication of a Draft

Requirements Document. This same period has resulted in two

contribution to the working group, one from CommerceOne and one from

Oracle. Both contributions reflect the requirements to date and the

discussions to date.


The Draft Requirements Document was very much a heart beat publication

and a work in progress. The F2F meeting in Seattle took this document,

examined it with a fine tooth comb and issued a list of changes. Both

contributions were presented and work was delegated to a small group to

move the contributions further along the track with a view to combining

the best of both of them and ensuring that they meet the current



The work at the F2F is clearly an indication that the working group is

moving to a convergent phase in it's life. We anticipate significant

progress in the coming months in which the Draft Requirements Document

is re-published and becomes a consensus publication in terms of it's

content. Furthermore we anticipate rapid movement to a single

contribution that becomes the strawman for the working group. We expect

the editors team and the contributors to meet regularly to this end and

we expect substantial results to have been achieved before the end of

the year.


We would like to thank the participants at the  F2F for their

sterling efforts and we would like to thank the editors of the Draft

Requirements Document and the contributors, namely CommerceOne and

Oracle, for their valuable input.


Martin Chapman and Steve Ross-Talbot



Role Call:


 Martin Chapman


Steve Ross-Talbot




W3C Staff Contacts


Yves Lafon












Yaron Goland

BEA Systems

Anthony Fletcher

Choreology Ltd

Mayilraj Krishnan

Cisco Systems Inc

David Burdett

Commerce One

Francis McCabe

Fujitsu Ltd

Yoko Seki

Hitachi, Ltd.

Eunju Kim

National Computerization Agency

Jeff Mischkinsky

Oracle Corporation

Nickolas Kavantzas

Oracle Corporation

Kevin Liu


Monica Martin

Sun Microsystems, Inc.

Jon Dart

TIBCO Software




            Invited Experts:


Jean-Jacques Dubray





Goran Ollson





Raw IRC logs at:          http://www.w3.org/2003/09/15-ws-chor-irc




Appointment of scribe:


Meeting scribes were: Nick Kavantzas, Tony Fletcher, Mayilraj Krishnan, Francis McCabe, Jeff Mischkinsky, David Burdett







SRT: Welcome to the f2f hosted by Attchmate

SRT: will do role call, then have a brief intro from the hosts, then on to agenda review




MC: role call (see above)


Attachmate was thanked for their very generous offer to host the meeting and they a brief company overview.

Since the last meeting, Jean-Jacques has joined Attachmate.



Review of agenda


Martin. Summarized what we are doing, transitioning from identifying requirements to writing the actual language itself

Martin. This meeting as about how we make this transition.

Martin. Continued to summarize published agenda


Changes and additional topics:

Tony Fletcher to present is Transaction requirements during Tuesday’s requirements discussion.

Specification Contributed by Oracle will be discussed Tuesday afternoon.

Janet Daly will attend Wednesday morning and talk about liaison.




Minutes from 9th September still need to be published so need to be reviewed at next con call.


Steve: Actions from mtg on Sept 9th:


ACTION:  David will deliver BurdettML proposal.

On agenda for this meeting. DONE


ACTION:  We should start using bugzilla effectively. This will be on the agenda for the next meeting. 

On agenda for this meeting. DONE


ACTION:  Members of the group must read the requirements Document before the F2F.

On agenda for this meeting. DONE


Steve. Will walk through the requirements document between 1.30 and 3PM today. Objective is focus on errors, omissions and redundancy, as well as any urgent wordsmithing.


Steve. Will people who have made comments on the requirements document, please point out the emails to Steve so that they can be included.



ACTION:Address the requirements with respect to the taskforces at the Seattle F2F. Chairs to place on agenda. We need to reconcile the requirements with the taskforces at the f2f, since they are implementing the requirements.

On agenda for this meeting. DONE


ACTION:SRT to change the location from Belmont to Bellevue. DONE


ACTION:  Members should send an email about dial-in requirements so that we can organize it ahead of time.

No emails received, so no dial in provided. DONE


ACTION:Directions to Attachmate MC/JJD

Sent to list. DONE


ACTION:SRT to send most recent requirements spreadsheet to the list. Ongoing


ACTION:Group will review Bugzilla issues list.

On agenda for this meeting. DONE



ACTION: Chairs, Oversee the organization of the task forces. 

On agenda for this meeting. DONE


ACTION: David Burdett to provide a design collaboration use case. ONGOING


ACTION: Martin to propose text for call-back use case.

On agenda for this meeting. DONE


ACTION: DB to produce a commentary on how Burdett ML meets (or not) the current requirements.

On agenda for this meeting. DONE


ACTION: SRT to send mail to the Semantics tag as to what he is looking for to initiate the discussion on semantics in the WS-Choreography language.

            LATEST (NEW ACTION): SRT Brought semantics question to the TAG. On chairs coordination call, he asked about semantics for/of choreography. A new Semantic Web Services Interest Group is being formed in about one month. Issue will be sent to that group when it is formed.





ACTION:Discuss F2F in Dec next meeting. On F


Need to fix next F2F - is it in Australia?


There will be more discussion later in the meeting, and need to make a firm decision.

On agenda for this meeting. DONE




Task Force Reports


Task Force 1: Harvesting


Monica. Updated Requirements Matrix.

Monica. Need to work out what we evaluate, e.g. BPSS

Monica. Analysis of the matrix and evaluation will help us identify gaps. Will try and complete the matrix for later on today and publish.


Martin. Who's been involved?


Monica. Mike Champion, Charles (ed: who is this?), Malraj. Haven't met since July although there have been discussions.


Martin. The task force was to look at existing specs rather than look at new proposals. Recognized you could have looked at the new specs (C1 & Oracle) using the same approach.


Monica. OK so I'm suggesting another activity.


Jon. These two proposals are core to the work of the group as a whole therefore should really be looked at by the group as a whole.


Monica. Can we use the categorization of requirements as a way to identify gaps as well as coverage.

SRT: URI for Oracle submission is: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0018/wscdl_v1.zip


Jon. Thinks this is a good idea.


Monica displays requirements spreadsheet/matrix  ( http://lists.w3.org/Archives/Public/www-archive/2003Oct/att-0000/AssessmentToReqtsCategories-mm1-091503_1.xls)

"Green column" is the list that the task force 2 categories identified. The Yellow column contains categories from the requirements.

The task force requirements were derived from a task force 2 brainstorming session.


Monica - let's start by looking at the gaps.

Composition. This maps to the TF idea of nested processes

Still need to include correlation - discussion still needed.

Steve. Computability - should refer to whether it is executable or not.

Jon. Should we go through this and measure against the requirements document.

Monica. Have we missed some of the topics? Do we map our study against requirements or do we map it against an area of functionality while recognizing that the requirements document is incomplete.

Steve. Two steps. This should feed into the requirements document anyway  i.e. make sure we have captured everything.

Next step is map into BPEL, etc.

Jon. Good idea to include out of scope section - Steve agreed.

Frank. How do we get the CSFs from this?

Steve. They aren't here. There's a whole section in the agenda to look at CSFs



Task Force 2: Semantics Task Force


Frank. Both Frank and Jim Hendler have had zero time to work on this.

Frank. Thinks that the importance of this work will show up later.

Tony. If you had had more time could you have made more progress, or are you waiting for language features to be developed?


Steve. JeffM, Frank. Discussion around need for semantics and how important it is.

Yaron. This group does not need to solve the problem of discovering semantics.

Yaron. Currently all usages of web services are carefully negotiated. Doesn't think that anyone will be ready for automated discovery any time soon.

Yaron. Recognizes that discovery is needed, but is not required soon and that we should focus on other topics first.

Yaron. Key issue is how do we work with a partner what our expectations are for choreography and discovery later.

Steve. Thinks Frank's & Yaron's points are reconcilable.


Steve> FM and YG views are not really different. They are, as Yaron pointed out (prioritization) and Frank (might not be what we do in this group) different views of the same thing.

Steve> FM semantics are not salt. We cannot sprinkle it on after the meal has been cooked.

Steve> JD the dominant focus is inside the firewalls so discovery is not an issue yet.

Steve> YG Discovery is a big issue for many of my clients. They ameliorate their discovery issues inside the firewall. They do it as a fudge so they do not need standards to get there now.

Frank. There is no energy within WSA to do any work on discovery.


David. Suggested how you define semantics is within scope.

Frank & Yaron - disagreed


David. All I'm suggesting is that we include descriptions at some specific place in the spec.

JJ. Agreed with David.

Frank. Our job is where in the description of the pattern of exchange in a choreography you explain what is meant.

Steve> DB do not want a generalized way of describing semantics - outside our scope. But for it to be useful our specs should be readable and understandable.

Steve> FM> U need a lot more for interop

Steve> YG Do we have a contribution to make there? Clearly if a chor spec is not understandable then that’s not a good thing.

Steve> YG There are 1st and 2nd order effects.

Steve> DB We should be able to describe the chor in English

Steve> Thoughts from SRT: Phew they all agree ;-)) Adding comments to chor is a good idea

Steve. Putting comments in code is good practice. But there is the problem of ill disciplined programmers.



Yaron. Should have a semantics section in the spec.

Yves. Semantics is just meta data.


Steve (wrapping up) ...

Steve. Need to ground this (as Jeff said). At lowest end have need for comments (David).


Make the language easier to read (Yaron). Need Ontologies (JJ & JefM).

Steve. Seeing layers where semantics can add value.

Steve. Next steps should be to summarize where semantics can add value.

Frank. We're still thinking of semantics like salt - makes the spec taste better.

Frank. We need to identify the key relationships within and between the elements of the language.

Yaron. Need to get our extensibility right so that others can more easily add in more comprehensive semantics.


Frank. Quote "You can’t do semantics on your own. It's all about relationships " ;)

Jeff: for the record: I didn't go as far as saying we "need" ontologies. More precisely the use of ontology technology -- to the extent that it's syntax/semantics are well-defined -- MIGHT be something that's grounded enough to be useful

Jeff: I like the suggestion wrt extensibility points -- it provides the perfect mechanism for people to experiment without breaking interop

   I view the use of ontologies, semantic web, rdf, etc. as not really being ripe for standardization


Steve reviewed the task forces: two taskforces set up:

harvesting existing specs & standards  (BPSS, BPEL, BPML


task Force 2: formalisms :Pi-calculus & Event calculus


more progress in the harvesting task force

comments on where task forces are and what they should be doing are needed

What value are we looking for from task forces

Nick is concerned with progress

Need a formal meeting structure for the task forces

More progress needed on task forces in the next few weeks

What are the next steps, what are the priorities of the task forces


Yaron: Need to work on requirements

Steve: Aim to get clarity on results of task force wrt input to WS-CHOR


            The task forces were further discussed later on in the meeting.




Steve: req doc produced by scanning email list for use-cases


Yaron: Requirements doc should be text based (i.e., should be explicative of the requirements)

Yaron: collect words for the glossary


Started reviewing each requirement looking at whether it is generally ok (maybe with word-smithing),

dubious, a duplicate or out of scope (deletion candidate). The requirements editors will take these as directions for another draft


Note 1. Specify the context of a requirement in terms of a CDL or its run-time instance

Note 2. Formatting/style: requirement should have an explanation as part of the description

Note 3. Should have been a CSF-based approach

Note 4. Glossary and glossary compliance


CR-14 needs word-smithing "Implementation"


CR-010: Wordsmithing needed (binding mechanism, diverse technology)


CR-023: more word-smithing needed


CR-004: contentious: What is meant by querying the state of a choreography

Choreography must be in an identifiable state

Must have state, must be describable, must be identifiable

Mutually visible states


Yaron: architectural principle? We are done when nothing left to cut. Will a given feature break applications if removed? Can it be added later without breaking anything?


CR-052 Unclear as to what it means

Tony: meaning needs unpacking

Should be requirements on the language, use of the language, instances of the language

John: Wordsmithing clarification needed


CR-053 wordsmithing


CR-056 wrong section. related to composition

Monica: is this to do with security?

Steve: Double quotes worry me



is implementation suggestion, not a requirement

management requirement: we have to be able to observe events and states


CR-016 is in the charter

wordsmithing needed should be a constraint


CR-020 implementation feature not part of the language

not needed

implementation requirements are candidates for deletion from requirements doc

Wordsmithing: instance is unclear,


CR-005 wordsmithing



CR-009 Why pick on time?

May be other kinds of event

Not the same as reliable messaging

DaveB: three sorts of events: sending messages, receiving messages, time has passed.


time is part of the observable state


CR-018: because it's SHOULD, leave for later


CR-026: the crowd cries out - what does robust mean?

Yaron doesn't think exception handling belongs here, since that implies if/then/else logic and he doesn't think we should have any of that sort of thing

could be reconciled if there was another level of handling

steve: I have a WS, and I have a choreo -- what happens if ws dies a horrible death -- is that observable to me -- if so, then need to surface this untimely death in "the choreo"


CR-026: clarify in conjunction with CR-005


CR-027: really 2 parts - err/fault and compensation

yaron can't see a req to distinguish exceptional choreos from normal ones

discussion about whether there is anything special about "compensation"-related messages and non-

martin: if part of bus rules between partners is "if you do x, then y happens" is the fundamental issue

steve: is there a reason to distinguish compensation mess? -- KEY issue


[The following were discussed on a different day but are placed here for continuity.

Chronological order can be found in the raw irc logs]


CR-030- Clarification on unhandled exceptions


CR-031 Possible Duplication



YG: one person is exception is another success.

DB: Talking about dependencies between chors.

FM: Does it amount to recursive state machine?

JD: sub chors error needs to be propagated to parent

YG: propagating the message. All internal implementation

JD: I am talking about message passing sense not java way

YG: that is ok

KL: Is there any use case related to this requirement?

MM: Does this relate to MM's use case?

Martin: Yes..

Clarification on propagation required



YG: Is there in scope for chor def? Is it the product will handle internally?

YG: it is out of scope

KL: How do we assign the messages?

YG: garbage choreography. Collect all the expired orders. Do we need?

How can I assign an error/exception message to a choreography instance that is not instantiated yet?

MC: Any body to defend?

YG: Configuration issue for message handling system. Not a s/w group for chor

DB: I can come up with one use case. Describing the req..

Candidate for deletion



JD: Roll up all the error related reqs.



YG: how we need to treat the message is not chor. business.

KL: Should not enumerate all the errors.

Steve: One partner cares and another partner need not care..

YG: WSDL does not have operations .. No url to receive all the messages.

Do we need to punt this issue?

JD: Do we need to application and system errors?

JD: If is not discussed sufficiently it will re-resurface

Further discussion, heading towards a deletion candidate


CR-61 Duplicate



Steve: process monitoring this and detecting

YG: Conceptually possible to monitor everything going on the system

KL: Does this belong to exception?

Steve & JD: Management category

Reclassify to Management and word smith


CR-65 & 66


YG: I don't like these

JD: It must collide the existing web service.

Candidates for deletion


TF: I think we need to have some model for chor. Each activity running on separate node.

TF: Diff instances should run. Actual model of the language should capture



JD: Drastic word smith needed

Major clarification ( the group doesn’t understand any of these)



YG: Unknown errors in WSDL (interpretation?)

Steve: do we need to classify the types?

YG: It is my business to capture the exception and sent to the other side. text message or something else

FM: You can answer that question with more conviction .Get more core concept in the chor.

May be everything is in message. But that is not the essence.  Notion of normal and erogenous chor.

It will make the diff when we compose.

Candidate for deletion


CR-69 Possible duplication


CR-070 Candidate for deletion



JD: better to describe in some other way (relates to reuse)

Need wordsmith (Chor vs CDL)


CR-007 Wordsmith (Must, apparent state of the exchange)


CR-011 merge with 007


CR- 029

Martin: signals vs business messages

JD: Can we move this to error handing category?

Steve: I think we can move to semantics section

Group: No..

KL: suggest for deletion

Candidate for deletion



YG: is it while loop?

TF & Martin: yes

YG: I agree with while loop and what about the termination?

Nick: Conditions may be public . Should be private (Question to YG) Why it should be ?

Martin: We need to have this debate… some time !

Further discussion required



Martin: What is the meaning of among chor?

FM: Chors are not agents..

Nick: Chor can not talk to another Chor.

Clarification (among chor) and duplicate , deletion candidate



JD: There was talk about minimal chor and would not put as a requirement

Candidate for deletion


CR- 55

YG: Assumption is correlation tied to chor.. But it really tied to WSDL

JD: This is about missing use case.

Martin: Ability to pass around ws end points

YG: I am ok with WSDL Expressible.

YG: Let us hope thru WSDL

Needs wordsmith ("Callback mechanism")


CR-060 Duplicate


CR-015 [ed: nothing record in log on this one]



MM: Is it a security requirement?

JD: What is the information that we expose to one partner..

            Wordsmith (Information hiding vs Segmentation)



JD: We don't have any protocol for negotiation

DB: Might be useful to have some context information in the chor.

Steve: Candidate for deletion

TF: does not belong in transaction not as a requirement.

TF: Could be in specification. Use chor instance what we agree with business partners.

JD: How it is different from use case.

TF: Could be use case. For language specification

Steve: Need Use case

Deletion candidate


CR-037 Reclassify ("Composition")


CR-038 Reclassify ("Composition")


CR-037 Wordsmith (What not how)


CR-038 Further discussion


CR-17 Probably should not be in Transaction category. To me it is saying that it is a requirement on instances of use of the language that they should be usable in negotiations between partners.


CR-048 Duplicate


CR-057 Reclassify


CR-058 Deletion candidate


FM: Are we giving a chance for authors to review?

Steve & Martin: Yes



TF: I am thinking of the way ebXML envisages partner negotiations which include agreement on technical aspects via a CPA.

A CPPA includes a pointer to the definition of the business process interchanges - currently a BPSS instance.

Could also in the future be a WS-Chor language instance. Should be something to this effect in the spec doc.

Martin: Multiple parties vs single party

JD: Do we have a use case to support this?

Martin: Def we need clarification

Martin: this is about sending same message type

TF: Can you do this at what price? Can you do it for 100 quantities? But same message type

TF: Then I can make the decision

Martin: Same party same message.

TF: I have some to add in the transaction

Clarification (of use case) needed.


CR-003 potential duplicate



CR-006 Duplication (KL: important requirement)




Leave in - effects bindings - but folk unclear on meaning

Same as 3? Yes 24 is duplicate of 3




OK but duplicate? About composition of Choreographies - clarify hierarchy in this requirement

 Clarification of hierarchy needed and maybe a duplicate.



Dynamic whereas 34 is static design time? But seem to be related.

Needs clarification.



What is 'parallel composition?

 David: a choreo can have two sub choreos that go on in parallel

Steve thinks maybe his requirement so he will clarify.

Clarification needed


Does this mean able to express sequence of events and events that can happen in arbitrary time order (in parallel)

Major clarification needed.



Not understood.

Major clarification required



OK but put in 'Re-use' category or make a new category for this - ref use case 4



Degenerate case if a choreo has a single entry point.

Probably OK if it said 'should'

Agreed it makes sense but not as a Req.

Candidate for deletion.



Required but maybe a V2 feature - low priority



Add 'from its viewpoint' Leave in here and remove / combine duplicate from elsewhere.

Wordsmith and potential duplicate.



May rather and may be V2

A “MAY” not a “MUST”, and possible a V2 feature.



Wording appears wrong way around.

Potential duplicate.



Possibly re-classify under semantics?

As an aside need some ease of use reqs!!




Imposes terminology.

Need to distinguish types of things and instances of things

Implies requirement for a model!

Needs major clarification.


Completed pass through Requirements


Steve proposed a process for going forward. Anything marked as a  deletion candidate needs another pass. We have to ask the group in the public mailing list..

Within the set period, if nobody if  defending then it will be deleted.

Steve: My aim is to allow the wider group to defend.


Jeff: How many times we have to make the decisions?

Steve: I am quite happy for suggestions.

JD: Aim is to come with the refined draft.. It is up to people to go thru and tell us what they like or don't like.

Steve: Do one more time sanity check and then we get to go.

Steve: we need some process for clarification of these?

JD: we stopped doing word smithing because of the time


YG: Editor get to do it  for unambiguous things.

JD: If we cannot the clarify then we can ask the wider audience

Steve: That is fine.


ACTION: Steve: Will put all the comments on draft requirements above into the requirements spreadsheet and send out.


In summary the group agreed that the editors should address the comments/suggestions listed above and propose a new draft. People should keep an eye out for their favorite reqs being deleted and defend them. Changes will be clearly marked so nothing should slip through.


Critical Success Factors


Frank to give us tutorial on CSF - Critical Success Factors

top down - identify goals -> CSFs -> requirements (must be measurable)

jeffm: requirements must be SMART : Specific, Measurable, Achievable, Realistic, Time-bounded


Goal brainstorm:

- capture the interaction of set of web service providers and requesters from a global perspective

 - peer to peer ws relationships

-  composability

- reusability

- segmentation

- not preclude interoperating with a number of emerging standards: e.g. bpel, reliability, transactional protocols

- language be usable by normal human beings

- interoperatibility and multiple protocol bindings

            - declarative global model

            - state alignment

- simple for simple things, complex for complex things

- verifiability

- implementability - spec should be usable immediately when finished without being dependent upon other specs

- extensibility

            - simplicity

- CDL should be distinguishable from implementation languages

- facilititate use of tools to manage and generate descriptions

            - machine readable

- mappable to graphical notation

- CDL should provide design-time and run-time validation

- enable recovery from exceptional conditions

- must be able to capture interactions in a mixed security environment

- we will be successful when we can describe a clear business case for the adoption of a choreography language

            - should be possible to be do third-party software validation at runtime

- must be able to express conditional paths

- not restricted to b2b applications

            - must have ability to express conditional start and completion

- should be helpful for generating skeleton for implementation and test cases

            - sufficiently abstract to be robust

- must support wsdl 1.2

            - must fit with the WSA

- low cost of entry for existing web services

- enable performance of one choreography to be dependent upon completion of another

- when exceptions occur, they must be propagated to different levels

- must not have any business semantics

- completion should be guaranteed, livelock and deadlock free

- concurrent execution of process

- reusability - write once, use many

- be able to express business processes

- correlate message exchanges

- important for CDL to be consistent with semantic web

- ability to specify various levels of qos

- expressible in terms of external observable behavior

- to enable the description of the semantics of the choreography definition to be easily specified

- computable

- scalable

- interactions should be atomic


A sub group met after the end on the days main business, to condense, and refactor the above list.

The results are captured in:


            The following discussion took place on Tuesday morning.



Now Frank is reviewing the CSF activity -- yesterday's continuation

Frank: I did some analysis and the number drop down.. is not final

Frank: Talking about main goals


Frank: Interoperability, S/W Engineering, Business Scope, Community responsibility

Frank: Main CSFs are Support for independence - technical environment (Peer to Peer, not tied to B2B and B2C, Security)

Frank: Another one Semantics (Global model, verifiable at run-time and statically, state alignment, composable)

DB: What does state alignment means?

Needs clarification from Nick.

Jeff: It is not 100% or atomic.. State has to be aligned with infrastructure

DB: It is about role to role communication?

Jeff: We need not read that much into these bullet points


Frank: S/W Engineering (Reusable, scalable, secure (foundations)

JD: It is not really S/w Engineering.. It is architectural things.

Frank: CSFs has to be scalable.

Martin: What has to be scalable?

Frank: whatever we propose


Frank: Tooling (easy tool) and graphical presentation


Frank: Time to market (Not dependent on Future specs, support on WSDL 1.2, Zero cost of entry for existing web services)


Frank: Fit in the WS landscape


Frank: Based on XML tech, clear relationship with BPEL, Semantic etc


Frank: Distinct from programming languages, machine readable/processable, expressable as externally observable behavior


Frank: Support for Qos, not attempt business semantics


JD: I am ok with not building business vocabulary

JD: We should be able to capture actual generic business use case

JJ: Nothing should prevent us doing by exchanging the documents

JJ: Enables Business semantics to be built on top of it.


Martin: I think we agreed to stick with technical level and not address business contractual level


Frank: should support testing external observers, test case generation


Frank: enable recovery, express conditional paths, conditional start, end points

Frank: Chain choreographies (kind of composition space)

Frank: Support concurrent execution (parallel activity

Frank: support message correlation


Martin: Did we capture everything that we discussed yesterday

Frank: Yes.. I did ..


JD: Explicit reference on XML

Martin: When we do know we are in a shape (where we capture all the reqs)?


Martin: Do we feel that we are all on the same frequency?

YG: I think that we do need initial sketch .. Go thru the requirements document

FM: Everybody has to make sure their favourite things are in the requirements

Martin: We have the whole day to review the use cases, reqs and we can come back

JD: Yesterday there was a feeling that we have too many CSFs and Goals

FM: we don't have that many. We have 6 main CSFs

JD: First pass is review, and second is word smithing..

Steve: Relationship between mission and goal (what way we derive. Mission from goal, Goal from mission)

Steve: Reading the mission statement from the last F2F

JD: If you go thru the list (requirements) that some of it may not be attainable.. I am quite concerned about it

Steve: We can go to use cases, come back to CSF (requirements session is in after noon)

Martin: requirements and CSFs are intertwined.


Requirements editors to insert cfs into the requirements document and suggest wording sympathetic to the discussion above.


Overview of WSA


Frank McCabe presented an overview of the WSA WG draft output:



Five models: Message Oriented Model, service oriented model, policy model, Resource Oriented model, Management Oriented Model




mm: in the policy section, do obligations cover business level

fmc: intended more for things like security, reliability, etc

fmc: tho not excluded



Use Cases


Steve: Use cases review, 11 in the document, do high level view of the use cases

Steve: What is the relevance to our requirements


YG: Better to go thru the requirements rather than use cases. But is my 2 cents. Not statement

Martin: Use cases demonstrating the features of chor.

Martin: If we can describe 3 or 4 illustrative use cases could be useful to the group. Not fragmented use cases


YG: David Orchard told me that we should start from the WSA use cases.

JD: Why should we expect WSA will describe the chor use cases


YG: They might have some. Clearly traveler use case.

Martin: They have use cases very much at the message level

Martin: We should take Travel use case.. But it may not detail all what we need.

Martin: We should tell WSA that use case 60% fit

YG: Yeah. That is ok.


Martin: Let us identify top level, variation etc


JD: WSA is actually looking for feedback from us -- when chor. has come up in their discussion, they have frequently said they are looking for material from WS-Chor to add to or modify the architecture document.


Monica: There are some use cases & discussion in email.


Martin: Everybody should have reviewed use cases. Any comments


MM: Let us detail the requirements from use cases and start drawing the complete elephant that Frank is talking about

JD: Actually I think lot of good material is in the use cases. It is presented sometimes without the context. I want something really easy to follow and comprehend

JD: We need to clearly present use cases retaining in a understandable way


Martin listed down 11 Use cases from the req document


Missing is callback, Multicast (Alistair’s) use case

Martin: we have to classify these use cases

Travel Agent, Quote Request, Really Big Corp all business type of problems


Martin: rest of them describing the features/variations  of a use case

MM: Look at the two that I described, we can integrate into any of the business use case


JD: Monica's or some of the use cases may not describe the business scenario


DB: Do we have any for Multiparty? (Buyer, seller, shipper). Roles are fixed.

MM: You can probably use Multicast use case to what David is talking about..

Martin: How do we go forward?

Martin: I kind of volunteer to lead this activity for classification


TF: Clarifying.. Concentrate on the business use cases (three or four) and see the requirements how fit into this.


JD: I don't think all the reqs will be traceable to use cases but most of them will be. Non-functional requirements

will fall into this category


New Requirements and Feedback




Kevin noted Ivana's mail with comments on Requirements


New Requirement from David:


It must be possible to have multiple participants with the same role in a choreography instance. E.g. you could have multiple suppliers all responding to a "request for quote". The number participating may be bounded or unbounded.


There was no objection to this new requirement, and the editors are directed to place it into the appropriate category.


Presentation from Tony Fletcher on business transaction requirements



YG: are these requirements part of the 80 side of 80/20

YG: no  as should be able to do this explicitly

YG: reserve the complex stuff for v2

YG: TX not the same as reliability

JD: if no mechanism in language then how can emerging protocols be used

NK: need a way to demarcate

MC: most languages have scopes

JJ: simple control flows in first version

JJ: need these types of control flows


Comments on proposed requirements (treating the same way as our previous comment processing)


Req T1: describe Business Tx Creation

JJ: suggestion split into control flow requirements, demarcation requirements and TX requirements

major clarification - more emphasis on what not how is required


Req T2: describe business TX reception and transmission

JD: says need transmission of TX contexts

NK: should propagation show up in a language?

TF: choreo can describe several different participants which may involve passing on contexts

MM: need to discuss what other sorts of contexts

TF: contexts are mechanisms under the covers

major clarification - more emphasis on what not how


Req-t3: describe involvement in buss TX as participants…

JD: how different is this from t1

NK: more of a role view

major clarification - more emphasis on what not how


t4: describe two-phase termination of buss Txs

major clarification - more emphasis on what not how


ACTION: Tony to rephrase his requirements and bring back to group.


Issues List


Martin demonstrated the  W3C Bugzilla pages

Use the public bugzilla pages rather than the member one




Click on Query existing bug report link then go to product = WS Choreography


Have to use notes and comments fields to add link to people / emails


Steve mentioned that there is a bug writing guide (only 22 pages!)


ACTION: Editors of the requirements are directed to look at the issues list and filter each issue in a similar way to the filtering method used at the F2F.


Martin still concerned that we have not agreed the total overall shape



ACTION: Steve to facilitate calling an Requirements / Use Case editors meeting


Language Proposals


Nick Kavantzas and Goran Ollson presents the Oracle WS-Choreography Language proposal


Proposal at: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0018/wscdl_v1.zip

Presentation at: http://lists.w3.org/Archives/Public/www-archive/2003Sep/0051.html


[note scribe wasn’t paying attention and missed a lot of the discussion]


ISSUE: Synchronisation on slide 14 of Oracle presentation - add straightforward support for asynch as well?


SRT: The react construct might be expressable in terms of some modified ECA language. At least the declarative nature of these might prove useful. A uri in support of this would be: http://www.haifa.il.ibm.com/projects/software/amit/ and a further one might be the work in the reaction rules subgroup of RuleML http://www.dfki.uni-kl.de/ruleml/


MM: It is important to note that for choreography, we

should recognize the interaction between applications within an enterprise where the most pain is felt by customers today. This would change the focus from the PO scenario in B2B that many discuss to the actual focus of the interaction between an ERP,CRM and SCM.

Jon Dart indicated the message request-response may not be that different.

Martin said the distribution, variability and some requirements may be different, such as for reliability, security and non-repudiation.

Further to Monica's point, it would be a good idea if we had a major EAI problem as a use case. Furthermore it might help in establishing the business case for using a CDL within and across the firewall.


ACTION: Requirements editors to consider an EAI use case and think about within and across firewalls.


Need to compare and contrast the Oracle proposal with BurdettML - will address that tomorrow


Guards currently use XPath but could be anything else

Yaron recommends not having in at all!


Presentation represents current thinking - need to see the extent it meets the reqs




David Burdett re-presented his slides on BurdettML:



Nick: What import does?

David: Import only collaboration types, not WSDL types

Steve: The underlying format is in a MessageFamily?

Nick: How do we do WS binding?

Yaron: We may use WSDL 1.1 operation for binding; point from MessageFamily to an operation

Nick: What about types; like state in David’s proposal; does it have a type?

Yaron: I don’t think we need state type at all


Frank: Dave you said: “Existence of a state can trigger an event”; what does this mean?

Steve: A new order has been magically created at the buyer, and as a result the state order sent is created that causes an event to occur. This is can be easily depicted by a labeled transition diagram.

Nick: synchronization is an important concept.

Yaron: Is this just a synchronization issue? Or is something more?

Nick: I am not sure if there is something more but I believe that state alignment is quite a fundamental issue. In Dave’s proposal, state transition can happens only at the endpoints. And there are no synchronization points, really.


JJ: can you compose interactions?

Dave: not yet

JJ: can we associate a response with a request?

Dave: yes


Nick: can we capture documents that are exchanged as states and use conditional logic on the content?

Dave: yes, using a binding but binding in not defined yet.

Yaron: it can be defined but not necessarily needed.


Frank: can two choreographies be triggered from the same start state?

Dave: yes

Frank: how do you know, which one you are using?

Dave: using identifiers in the message associated with the message instance

Frank: if there more instances?

Jon: what is the mechanism?

Dave: use payload, header

Frank: is this correlation problem?

Yaron: not exactly

Frank: correlation is bigger a bigger problem: associates a message to a context


Yaron: the question is in a choreography, does one role know what the other role does?

Jon: the difference is that Oracle Corporation proposal tries to also align state

Yaron: I only care about what happens at one role

Frank: what are the preconditions of sending and receiving messages

Yaron: I understand the utility of synchronization, but is this the ONLY thing required?

Nick: What I am saying is that both models, the role-view and the shared-view with synchronization are important to be treated as first class citizens. Not just one or the other.


Frank: Buyer is only concerned for making a decision, why the seller needs to know this in choreography?

Yaron: It is important to show in choreography only if it is important for both roles

Frank: so, you don’t need this precondition but the seller does not need. This cannot be validated at runtime.

Jon: don’t you need precondition to validate invalid message sequences?

Frank: what are the cases we need precondition we need to investigate more. How this works for a third participant?


Nick: in interaction the fromRole-state transition and the toRole-state make transitions. Does this need to be atomic?

Dave: no, because of failures


David says: BurdettML could live without processes (see slides)

Nick asks what can be imported? Can I import WSDL types?

David answers: No only roles, message families (which are a collection of concrete message types)

Yaron suggests that today BurdettML is best serves by pointing at a specific WSDL message as opposed to a Message Family

Yaron: Would like to get rid of pre-conditions/post-condition (probably see Yaron's email about BurdetML from one/two weeks ago)

Various questions seeking clarification about BurdettML. In brief it was all around the notion of two state machines that work harmoniously in some what. This is at the heart of what BurdettML is all about.


David made the point that *this* version has no composition features.

One of the problems with the FSM approach (I think and correct me if I am wrong) is that much of the static analysis that is targeted for V2 of a CDL would not be possible. So one of my concerns is that we lock ourselves out down stream. Given that David has already made it clear what he feels are "the things yet to do" it may be the case that this is a solution that lies somewhere between the two current submissions. This would be consistent with Nick's view.


ACTION: SRT send revised requirements spreadsheet to David


It was agreed that the authors plus other volunteers meet to discuss the possibility of merging the two proposals into and single baseline.


ACTION: Dave will call a meeting, to discuss how to take the two CDL contributions and come up with a baseline document and match it with the revised requirements document.


Someone asked why we didn’t start with WSCI as the base language.

Martin replied that no one had proposed it as a baseline. They are free to put such a proposal top the group if they want.


Dart: WSCI is difficult to use because it is primarily a participant model and uses the global model secondarily.


Tony: Input TF should look at existing specs rather than evaluating these new proposals to us. This meeting should be watershed - complete Reqs / use case even if not perfect, start work on actual spec.




Janet Daly W3C Communications Spokesperson was invited to talk at the meeting.


Janet: The message is that the work from W3C Choreography group and the BPEL group should be complementary.

Yaron: I agree.

Jon: WS-Choreography WG has a long-term schedule. We have a requirements document now. What is the best way to communicate intermediate results?

Janet: your mailing-list, summaries of issues, background papers on issues.

Also, individual companies can do more to promote progress, success.

Steve: It is tricky to get a group of people of this size to focus. One way to make this is understand what is in the horizon. What should we look for the next 6 months?


1) The 17-19th November is the next W3C publication moratorium. Publication requests cannot be received after 12th of November 2003. This group should try to meet this date.

2) Philadelphia, XML 2003, December second week.




Tony Fletcher presented an overview of the UN/CEFACT Business Collaboration Framework (BCF):







  (Originals at http://webster.disa.org/cefact-groups/tmg/bcf-tour/agenda.html)



Jon: Are there any business applications on this?

Monica: no


Ran out of time so no discussion as to whether we should form a liaison with UN/CEFACT.



ACTION: Chairs to put liaison with UN/CEFACT on next con call agenda.



Planning and Roadmap and AOB


Steve: Goals


1)     Task Forces

a.      Objectives

b.      Roadmap

c.      What is their function?


    There should be 2 task forces:

      A) Harvesting against requirements and



The group felt that now we have a clear mission and a good understanding of requirements that this harvesting work will not result in useful input.


Motion to close this task force. Passed.


B) Formalism task force.


Motion to close this task force. Passed.


2)     Requirements

a.      Roadmap

b.      Participation


Requirements editors will meet and take into account the discussion made at the meeting in coming up with a new draft.

Aiming for a publication date on November 3, 2003 for public consumption. Internal drafts will be made available.


3)     Choreography Language Contributions


Authors have a agreed to meet and hammer out a baseline.

We would like a baseline language for the next F2F in December


4)     F2F December 2003

a.      Motion to accept the offer F2F December at Australia. Passed. Results are: 5 yes, 4 no, 1 abstained.


5) Motion to accept the contribution from Oracle. Passed.


6) Will skip next Tuesday’s meeting. Next con call meeting on 30 September 2003 1pm pdt



Summary of New Actions:


ACTION: Steve: Will put all the comments on draft requirements above into the requirements spreadsheet and send out.


ACTION: Tony to rephrase his requirements and bring back to group.


ACTION: Editors of the requirements are directed to look at the issues list and filter each issue in a similar way to the filtering method used at the F2F.                 


ACTION: Steve to facilitate calling an Requirements / Use Case editors meeting.


ACTION: Dave will call a meeting, to discuss how to take the two CDL contributions and come up with a baseline document and match it with the revised requirements document.


ACTION: Requirements editors to consider an EAI use case and think about within and across firewalls.


ACTION: Chairs to put liaison with UN/CEFACT on next con call agenda.