W3C

WS Description WG Teleconference
2 May 2002

See also: IRC log

Attendees

Present:
 Mike Ballantyne        Electronic Data Systems
 Keith Ballinger        Microsoft
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Macromedia
 Youenn Fablet          Canon
 Sandeep Kumar          Cisco Systems
 Steve Lind             AT&T
 Kevin Canyang Liu      SAP
 Michael Mahan          Nokia
 Pallavi Malu           Intel
 Jonathan Marsh         Microsoft
 Mike McHugh            W. W. Grainger
 Jeff Mischkinsky       Oracle
 Dale Moberg            Cyclone Commerce
 Jean-Jacques Moreau    Canon
 Don Mullen             Tibco
 Johan Pauhlsson        L'Echangeur
 Jochen Ruetschlin      DaimlerChrysler Research and Technology
(till xx:30) Arthur Ryman           IBM
 Adi Sakala             IONA Technologies
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 William Stumbo         Xerox
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Don Wright             Lexmark
 Joyce Yang             Oracle
 Prasad Yendluri        webMethods, Inc.

Regrets:
 Michael Champion       Software AG 
 Laurent De Teneuille   L'Echangeur 
 Tim Finin              University of Maryland 
 Jacek Kopecky          Systinet 
 Dan Kulp               IONA 
 Philippe Le Hgaret    W3C 
 Waqar Sadiq            Electronic Data Systems 
 Dave Solo              Citigroup 
 Sandra Swearingen      U.S. Department of Defense, U.S. Air Force

Absent:
 Mike Davoren           W. W. Grainger
 Dietmar Gaertner       Software AG
 Mario Jeckle           DaimlerChrysler Research and Technology
 Tom Jordahl            Macromedia
 Michael Mealling       Verisign
 Stefano Pugliani       Sun
 Krishna Sankar         Cisco Systems
 Daniel Schutzer        Citigroup

Chair: JonathanMarsh Scribe: DavidB

Contents

Agenda Items

Approval of Minutes

JM: Approved

Review of Action Items

ACTION: 2002.04.04 Editors to get CVS requests to Philippe. - PENDING

WITHDRAWN: 2002.03.07 Keith. Discuss open content model design.

ACTION: 2002.04.10 Sanjiva - add inconsistent use of port and endpoint to issues list equivalence of wsdl document - PENDING

WITHDRAWN: ACTION: 2002.04.11 Keith B. will write up descriptions for issues discussed in presentations and add to issue lists if not there yet. due date: next conference call.

ACTION: 2002.04.11 Jeff Schlimmer Add UPNP example to use cases. - PENDING

ACTION: 2002.04.18 Waqar will post by next Tuesday a draft. - PENDING

ACTION: 2002.04.18 Sanjiva Add 5 new issues raised by Prasad in to the issues list. - PENDING

ACTION: 2002.04.18 Waqar Add new use case raised on the mailing list - PENDING

ACTION: 2002.04.18 Prasad Write up question for XLANG and/or WSFL groups whether they need solicit-response. - PENDING

ACTION: 2002.04.18 Jonathan Solicit input from XLANG and/or WSFL groups whether they need solicit-response. - PENDING

ACTION: 2002.05.02 DavidB to get June F2F registration link working

Usage Scenarios Document

JM: We missed the pub blackout deadline. So should we go ahead and publish it, or start working with the Arch group?

Arthur: There are 2 cases. One kind describes Web Services.
... The second kind pertains to WS description documents.

Sandeep: A third kind is more of an illustration of different features.
... I think we have to sync up with what the Arch group is doing.
... I think it would be useful to cover use cases that illustrate issues that we're discussing.
... David Orchard has some scenarios, and there is a task force of about 15 people in the ARch group working on this.

Jeff: He basically collated the work of the Arch group.

JM: SHould we publish, or put our eggs in the coord group basket?
... I would like to go forward with publishing in a couple of weeks.
... And maybe today we can get some Volunteers to populate a joint task force between our group and the Usage Scenario task force in the Arch group.

DavidB: I think that'S a good plan.

Others: Yes

JM: WHo wants to be a part of such as task force?

Sandeep: I think there was going to be another telcon for the Arch group task force.
... So maybe we should join that.

JM: THat'S fine.

ACTION: 2002.05.02 JM to send a message to Chris to have members of the Desc WG to join the Arch WG Usage Scenario task force.

Volunteers: JeffM

Igor

Already members from the Arch WG: Sandeep, JeffM, Igor, Waqar (absent, but proposed by JM)

S/Already members/Volunteers/

Igor: WHat is our objective?

JM: We want to differentiate between Usage Scenarios and Use Cases.
... The Arch group will handle the Usage Scenarios. We'll take the Use Cases: How they apply to the description language.

Igor: But many will apply to both. THey will simply have components that apply to the Desc group.

JM: The task force can figure that out.

JeffM: I envision one document with pointers to pieces that are owned by different relevant groups/subgroups.

Issues

JM: New draft. Thread: http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0059.html

JM: let'S talk about Open Content Model.

Open Content Model

JM: Making a distinction between a feature of communication tthat is required, versus a feature of the description.
... What if I have some part of my WSDL doc that is encrypted?
... THe processiing model says to decrypt, and now I see messages and ports.

Glen: It seems that anything you'll mark "must understand" would imply that it would be needed for communication as well.
... I think "required' implies "must understand".

DavidB: There are three kinds of potential "must understand" features:

1. Must understand all features of this WSDL doc

2. Must understand all communication-related features that this WS needs

3. Must understand all of the features that this WS offers.

Glen: The third category is not relevant.

Roberto: I tried to classify what extensions can do for us.
... I would argue that having a "must understand" is a big hammer, and we're about to hit all problems with it.

Sandeep: I think we should pursue the path that Roberto has outlined.

JM: He split the extensions into three categories: Language, Architecture, and Metadata

Roberto: Metadata extensions should not be required.
... Language extensions are semanticly relevant.
... WSDL doc should be clear about which language docs are needed.
... But we should be able to say that this whole vocabulary is required.
... The third category is Architecture extensions. These pertain to bindings.
... If Language ext are clearly marked, then you can always tell if an element is a language ext, so you can distinguish them from Architecture extensions.
... So if I Don't understand this binding, then I won't understand the service.
... I Don't see a need for "required" or "must understand" per se.
... There shouldn't be a need, because the consequences of not understanding somethign are clear from the spec.
... By separating into these four cases we can clarify what they actually mean.
... The fourth category is the case of a feature for requiring something like encryption.

JM: What'S the best mechanism for allowing metadata?
... Is it the open content model?

Second question: Is there something new here that isn't in WSDL 1.1 that we need to develop?

Roberto: Architectural extensions Don't need a "required" attribute.

JM: So your proposal is not to make changes to the arch ext in WSDL 1.1.
... Do we want to allow Language ext? If so, do we want a fine grained mechanism, like an attribute?

Roberto: We Don't need a WSDL "required" element that can go anywhere.

JM: I propose we churn on this another week on email, and seek a specific syntax for each of these issues.

Igor: Are we going to have another discussion about langauge extensions?

JM: It'S part of Roberto'S proposal.
... I'm hoping that Roberto will refine his proposal.

Igor: I just sent fixes to part 1.

Solicit/Response and Output Only

Prasad: I still Don't see how it would work without Solicit/Response.

JM: Maybe Sanjiva can explain how to accommodate this.
... Roberto had an inbound/outbound flag, for example.

Keith: I agree with Prasad. It seems that to future-proof we need to accommodate both.

JM: Sanjiva'S issue was that it'S not described well enough at present.
... So if we decide it'S a good thing to include conceptually, then we'll need to tighten it up.

Igor: We should provide Use Cases that motivate this.

DavidB: I agree.

Prasad: We do have use cases, but not in the document.

Igor: But the use cases should consider WSDL and SOAP and not orchestration.
... It should be possible to do notification with only WSDL/SOAP.
... If we have definitions of Solicit/Response in WSDL, then it should be possible to make it work.

JM: I'm not sure that follows.

Roberto: We should consider complexity. If we have only two type, that'S half as many cases to consider than 4 types.

Prasad: Complexity is one aspect, but if it'S necessary, then we may have no choice.

DavidB: We need scenarios that demonstrate the need.

Prasad: But we have situations that need them.

x: I agree with Prasad. I might have a "product available" service. We Don't have a good way of describing the setup of that kind of thing.
... Such services are useful.

S/x/Dale/

Igor: We need to describe how that happens.

Prasad: Do you see two kinds of notification?
... Where the subscription is done outside of WSDL?
... Or when it is done within WSDL?

S/Prasad/Sandeep/

Prasad: Both

JeffS: I partly disagree with Igor.
... Sometimes specs are partial. If we thought there would only ever be one spec, then we would just let them define it. But if we aren't sure if there might be several future specs coming, then maybe we should define as much as we can for these Others to use.

Igor: It is a standard for a description. If it doesn't describe what happens btwn two parties, then it hasn't achieved our goal.

JeffS: I think Events are important.
... Even though we shouldn't wait to fully understand them.

Igor: We need to be complete. We need to at least know how it is being used.

JeffS: One problem is that there isn't yet an Orchestration WG.

JeffS: I propose we look carfully for examples of how these mnight be used.

Sanjiva: Outbound operations have had no use. I Don't understand why we want to keep them.

JeffS: I am concerned that what we needed in the past may not be adequate.

Sanjiva: ROsettanet and EBXML do not use it.

Prasad: A lot of this comes from RosettaNet trying to do this.

Sanjiva: What do these operations mean?

Prasad: Party A sends something that Party B receives, then Party B sends something that Party A receives, and this can go on indefinitely.
... You define the services on their own, then you put them together into business processes.

JM: We need someone to define more clearly what these operations mean.

Dale: Why do we want to remove them? Because we Don't want to take on the work?

Roberto: For simplification.

JeffS: I understand the value of specifying both client and Server sides, and I Don't think it'S the heart of the issue of whether it happens to be expressed in a single port type, multiple port types, etc.
... There is a question of what infoset do you want to use to describe them.
... Is there anyone who pushes back on the idea that we must provide a way to describe outbound messages?

Sanjiva: With a destination?

JeffS: Not necessarily. Maybe only the message type.

Igor: What you're describing will break interoperability. Currently WSDL describes I/O sequence and everybody knows how it works.
... I think we need enough information to carry out notification.

Sanjiva: If you have an output operation and a port type, what would the address mean?

JeffS: I'm not sure an address would apply to outbound operations.
... I think there may be value in describing outbound messages without addresses.
... Things may need to be able to match inbound and outbound types.

Glen: That may be dangerous.

DavidB: Can output-only events be modeled as reponses in a normal request/response model?

Glen: Yes, but you also need to handle multiple responses to a single request.

MEETING ADJOURNED

Summary of Action Items

Valid HTML 4.0! David Booth
dbooth@w3.org
$Date: 2002/02/19 16:35:31 $