1. Role Call
2. Confirm scribe
The following is a list of recent scribes (in order): Mayilraj Krishnan ,Francis MacCabe, Mike Champion, Abbie Barbir, David Burdett, John Dart, Carol MacDonald, Yaron Goland, Daniel Austin, Jim Hendler, Peter Furniss, Ed Peters, Greg Ritzinger, Leonard Gresk
3. Approve minute
Minutes 13th May 2003
4. Action Item Review
5. WS-BPEL update
6. Requirements general update (DA)
7. Issues editor – we need to appoint someone (volunteers please)
8. Use cases
9. Mission Statement
Revised mission statement – no link as yet
10. WSDL vs non-WSDL
a. See templates and abstractions above
11. AOB.
|
Chairs: |
|
|
|
Oracle |
||
|
Enigmatec |
||
|
|
|
|
|
W3C Staff Contacts |
|
|
|
|
|
|
|
|
|
Members:
|
BEA Systems |
|
|
Choreology Ltd |
|
|
Cisco Systems Inc |
|
|
Commerce One |
|
|
Enigmatec Corporation |
|
|
Fujitsu Ltd |
|
|
Hitachi, Ltd. |
|
|
Intalio Inc. |
|
|
Intalio Inc. |
|
|
Novell |
|
|
Oracle Corporation |
|
|
SeeBeyond Technology Corporation |
|
|
Software AG |
|
|
Sun Microsystems, Inc. |
|
|
Sun Microsystems, Inc. |
|
|
TIBCO Software |
|
|
W. W. Grainger, Inc. |
|
|
W. W. Grainger, Inc. |
|
|
webMethods, Inc. |
Raw IRC log at: http://www.w3.org/2003/05/20-ws-chor-irc
Len Greski, W. W. Grainger, kindly volunteered to scribe for the meeting.
Draft minutes at http://lists.w3.org/Archives/Member/member-ws-chor/2003May/0051.html
Martin:Jean-Jacques not on attendee list
the admin page has a link to the most up to date minutes
JDart: will accept them as they are.
SRT: previous minutes accepted
Minutes approved with role call updates.
SRT: proposes no call for next week, due to other conferences (BPEL / Budapest)...
Austin: prefers not to cancel meeting.
m2: I will be on the plane
consensus that 4 people would be available for the call...
mchampion: I will be available
Austin: if we won't have a quorum, we should reschedule.
Mchampion: Does the charter define a "quorum"? The W3C process doesn't AFAIK
Martin: readdress this at end of meeting
Austin: could substitute editors call
ACTION: Yves@W3Cshould ensure a registration page for f2f
Done (http://cgi.w3.org/Register/selectUser.pl?_w3c_meetingName=WSChorJun03)
ACTION: Daniel to post logistics information .
In progress - Logistics for F2F: Austin will post by EOD 5/21.
ACTION: John Dart to summarize WSA position on choreography wrt mission statement and goal
Done.(waitingcomments)
ACTION: Summarize use cases from privacy discussions
Unassigned
Martin: suggest dropping action item summarizing use cases from privacy discussions
JDart: agreed to do this action item
NEW Action: SRT to extract summaries of harvested specs (wsci, bpel)
ACTION: Carolto look into WSCI summary
Inprogress
carolMcD: Still working on WSCI summary
lmgScribe: WSCI summary -- still in progress
ACTION: SRT to capture reqs from minutes
No progress.
ACTION: All: alternate formal models other than the pi-calculus
Agenda item for nextF2F – proposal from FM
SRT: Alternate formal models -- can we have Jean-Jacques talk about this?
Frank: offered to give small presentation on event calculus
Daniel: need to talk about groves & hedges (hierarchical mathematics)
NEW ACTION: co-chairs to harvest agenda items for F2F
ACTION: Yves to setup reading list page. SRT will work with Yves.
In Progress
ACTION: DA will do the wordsmith, summarize and put together revised statement. Once again it is not final.
In Progress
Daniel: "wordsmithing" is on the mission statement, will be done in the next few days.
ACTION: YG to email what is meant by “Templating” and the benefits thereof
Done
SRT: templating, abstraction action items are complete, as well as BPEL information.
Yaron was asked to complete BPEL summary, and it is awaiting comments.
ACTION: DBto email is meant by “abstraction” and the benefits thereof
Done
ACTION: GRto email an independent view of what these terms might mean and the benefits thereof
Done
SRT: opinion on WSBPEL -- most important thing is that co-chairs of WSBPEL agreed to come to the F2F.
SRT: much debate about licensing and royalty status of BPEL 1.1.
CarolMcD: licensing questions surprise surprise
Austin: what was sense of majority of group?
SRT: a lot of the call was about trying to understand the licensing, because it's not clear. Pauls raised this as an issue, David asked as well. SRT gave an amendment, but not sure whether it was accepted (due to issues with Robert's rules).
SRT: big question is will they give it license / royalty free? We weren't sure whether we had a problem, needed to directly address it. We don't know whether there will definitely be a licensing problem.
tony: probably won't be a license fee because big players won't want to be sued over IP.
tony: starting point of debate was that bpel 1.1 spec was formally submitted on behalf of 5 companies. It was made clear that assuming that some aspects of spec survive into the final version. The TC did not vote to adopt or formally do anything with the spec. First assumption is that material submitted actually survives. Starting condition is that if you implement the spec, you would have to apply to 5 companies and get licenses from each one. This cause
Paul Lipton: I did respond to effort to rationalize original proposal. I inserted 2 items, SRT's original question, do 5 submitters give up licensing / no royalties? Also added suggestion that if 5 submitters are unwilling to withdraw license requirement, that they consolidate licensing due to time requirement for implementers. Much focus on royalties, but exact nature of restrictions, commonality of restrictions between companies may be a more significant
Paul Lipton: copyrights are on BPEL 1.1 submission, but not clear what IP issues are for derivative works.
Austin: does OASIS require companies to review IP related to submissions?
Tony: real issue is do the 5 companies have any patents related to the spec, is there anything new or novel? If nothing to patent,
they have nothing to license.
austin: w3c has faced this issue with "smile issue". afterward, very strict policy on revealing all your patents. Based on discussion, they're not approving anything we can implement.
Jdart: similar situation with WS security specification. When I read the bpel 1.0 specification, it says we may have IP associated with the spec. Specifically says we aren't conveying a license for the IP, it's very much an open area.
austin: anything that's a standard shouldn't require a license fee
Mike Champion: why did I think that this is available under an RF license?
Yaron: The authors of the BPEL spec have committed to a RF license and that the issue in the OASIS BPEL TC is that it appears that in order to take advantage of the RF license you have to go to each one of the spec authors individually and ask for the rights to the license.
SRT: i am a nominee for liaison between OASIS & W3C
SRT: Yves, with respect to my nomination, does W3C have a position.
austin: divided requirements into 2 tasks. Daniel will organize document, suggestions for non-use case based requirements. Abbie has taken task of converting use cases into template.
austin: hoping to have new draft as soon as meetings stop.
austin: is there an urgent need for publication prior to F2F?
srt: sooner we have a date, the happier we'll be.
daniel: I will talk w/ Abbie and get a date. Will publish at the latest at least 1 week prior to F2F.
srt: will hook up with Abbie @ budapest.
Duncan Johnston-Watt volunteered to be issues editor.
Clarification was sought as to whether there would be conflict between having the same company as issues editor and co-chair.
Martin C said he didn’t think it was a problem, and that the members will monitor.
DuncanJW appointed as issues editor.
An overview of Yaron's use case:
Yaron: net of entire paper is supposition that there are 2 entities (CPL - choreography process language) is the language used to execute a business process. CDL (description language) describing legal message exchanges, understanding end to end behavior of system.
yaron: purpose is to allow you to validate behavior of system: system of messages received & sent by a participant are compliant with allowable sequences as defined by CDL. Waiting a day or 2 before responding to traffic on email list. Main objection on list is the execution. I make strong case in paper that CDL is not executable. Executable is a lousy term, it used to be declarative
and that was a lousy term as well and I was looking for suggestions for a good term. Is the CDL something you would run to execute business process?
yaron: whole point is NO, describes, does not encode business logic. CDL encodes the allowable message sequences but
doesn't encode the logic used to decide which specific message to send.
yaron: goal is to radically simplify complexity of choreography. as far as executable issue goes, if we're trying to create an execution language, that requires us to solve a lot of hard problems (prog language, variables, etc.). BPEL is already doing this. If it's the right path, than we should take a normative dependency on BPEL.
yaron: successful CDLs are not executable. Example: BPSS has guard statements, none of our customers use them and few products implementthem. Therefore we need to focus on non-executable aspects. We can produce a very useful standard quickly, certainly faster than BPEL spec.
austin: does it make sense to accelerate timeframe w/ respect to BPEL? If we cooperate we should coordinate timing cycles so that we're not too far ahead of them.
yaron: trying to synch with a 100+ member group that just got started would put our schedule at the mercy of their schedule which doesn't seem to make sense. What we're doing has enormous merit / value on its own, regardless of what happens w/ BPEL.
yaron: we need to recognize BPEL is there, our interactions with it.
Martin: since we're focusing on 1.2 and they are on 1.1, there will be inconsistencies in our work.
monica: you had asked about executable CDL, there are implementations of this (BT, Verizon (?)).
monica: when integration happens, we need to address JJ's concerns.
yaron: what would make this happen faster... issue of executability needs to be clear by making clear use cases and determining how CDL would handle it.
monica: terminology, context. Handoff vs. physical instance execution.
yaron: way to come quickly to closure is to generate the use cases and see how the CDL works.
david: I agree with yaron, idea of CDL is a good one. confusion over executable is difference between definition language executable in software, vs. rules for behavior in a set of roles.
david: this will be very valuable.
yaron: this is similar to what i've been saying.
david: other concern is input into design time when developing choreography language to implement a role. language acts as a constraint on what the programming language can do. rules are particular to an individual role. This segment of choreography language could be used at design time, to generate part of programming / orchestration.
yaron: if you dig far enough into UC document, you will find example where I do exactly that: use CDL, tell it what role is being implemented, then use that to generate skeleton for CPL.
yaron: had formal requirement to determine necessary features to convert CDL to CPL, or vise-versa.
yaron: i know this is impossible in the general case, but may work in a limited case. if you have code you know will violently change, you may want to be able to round-trip the code.
tony: you're better staying with CPL than going back and forth. This is very complex.
david: posted example diagram of messages today, similar to your paper.
jdart: yaron is envisioning hierarchy in choreography languages. definition is high abstraction, may be higher level. there is also an abstract message, abstract process definition, and executable definition as we find in bpel. this is an interesting concept, not sure that 4 levels are necessary. also concerned that if we're going to have a complete solution, you need more than one level, an the levels need to feed into each other ala WSCI / BPEL connection
david: need to document how people in this business are going to use the definitions. need to expand definition to include exact services in a specific instance. Need template business process like bpel, which needs to be compliant with choreography definition, plus concrete implementation.
david: this is a useful separation of levels of abstraction. Without high degree of reusability, it won't scale.
david: need to identify languages, why we need them, before we define them.
Mchapman: reuse and scalability are orthogonal concepts
david: need to understand levels of CDL (e.g. template).
martin: we have requirements re: abstract & concrete messages. Discussion is too abstract without concrete languages.
jdart: can we discuss templating as a separate item?
martin: need to extract requirements from yaron's use case.
austin: we'll probably list them in the requirements document.
yaron: just cut & paste into the document, don't edit it.
srt: thanks for sharing use case, yaron
ISSUE templating issue needs separate discussion
srt: will come back to mission next time, would like to talk about WSDL vs. non-WSDL.
Since the wordsmithing hasn’t finished will defer to next meeting
austin: offer 2 alternatives, one specifying WSDL and XML specs, the other doesn't.
martin: my comment is that it is healthy to have the discussion. from chair perspective, who agreed to take on the charter, is that this is non-negotiable. That is WSDL IS in the charter.
martin: if the group strongly believes that choreography shouldn't be wsdl based, then we should clarify it or recharter.
yaron: amen w/ martin. we're wsdl 1.2, but i also agree we need a vote / straw poll. Are there people who don't want to use wsdl 1.2, can we use it until we run into a problem?
SRT: i'm 1.2 also
tony: i haven't heard anyone contest that the group shouldn't use wsdl 1.2. Point of contention is whether it is SOLELY wsdl 1.2, or a language that has binding to 1.2 component? Do we allow for anything else?
Mchapman: if you allow more than wsdl then you have to invent a neutral layer above
Mchapman: that is too much work IMHO
austin: I agree w/ tony's comment, I hadn't thought in terms of wsdl or not, rather wsdl vs. wsdl + other things. My position is that wsdl will be around for some time, but it's not the only thing we'll deal with. we need to design standard so it's not wsdl specific, so it can work with other standards.
martin, i agree that a neutral layer would be required.
srt: to use layers of abstraction to get reuse, but there are different views on how to get reuse. Templating vs. abstractions.
Ygoland: I agree that a neutral layer would be required and I agree that this is way the heck too much work for this group to take on.
srt: asked people to write 3 positions, these are circulating over the mailing list.
Mchapman: plus what would a neutral layer look like - schema? wsdl messages (which are converging on scheme), ...?
srt: just to clarify, the charter says "the languages should build upon foundation of wsdl 1.2". Doesn't say exclusive, but wsdl 1.2 is the focus.
Ygoland: The neutral layer would have to re-invent the WSDL 1.2 features in order to provide a full but abstract mapping.
srt: if it turns out we need other things, it's ok as long as we focus on 1.2.
austin: we don't want to tie ourselves to 1.2 version of specific thing, but a wsdl-based interaction model.
Arkin: big +1 to the stack approach
yaron: this is why we should push it to a vote. Last comment on wsdl issue.... In practical base, I have problems getting compatibility because all components want to be independent. Point Jon made on last phone call is J2EE stack approach, where releases guarantee components work together. WSDL will be around for a long time, if we support it that will be a good effort.
Mchapman: +1 to Yaron
david: need to focus on consensus about what problems we're trying to solve. Concern about wsdl, define choreography where halfway through you want a phone call. Don't know for certain that you could describe that sort of interaction with wsdl. If not possible, there's a whole set of choreographies that cannot be defined with wsdl.
Mchapman: i dont think wsdl can handle non machine to machine comms, nor do i think its a requirements for us
david: need to realize consequences of limiting to wsdl 1.2 if interaction above can't be defined.
Ygoland: We should get issues like the telephone as a requirement, I would hope we can model it as a web service. I believe we can.
m2: Can't a human be a service component?
Mchapman: do you speak wsdl messages?
asaf: we should look at it as a stack, bigger issue to W3C, not just our group. I submitted a use case depicting this. Let's look at hte UC and discus it.
srt: is there still a pressing reason to do call next Tuesday?
jdart: let's just make progress in email.
srt: motion to cancel next week's call.
No objections
srt: we will reconvene 2 weeks from today.
ACTION: SRT to extract summaries of harvested specs (wsci, bpel)
ACTION: Co-chairs to harvest agenda items for F2F