Web Services Description Working Group Teleconference
23 May 2002

See also: IRC log

Attendees

Present:
 Keith Ballinger        Microsoft
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Macromedia
 Dietmar Gaertner       Software AG
 Mario Jeckle           DaimlerChrysler Research and Technology
 Jacek Kopecky          Systinet
 Sandeep Kumar          Cisco Systems
 Philippe Le Hgaret    W3C
 Steve Lind             AT&T
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Microsoft
 Jeff Mischkinsky       Oracle
 Don Mullen             Tibco
 Arthur Ryman           IBM
 Waqar Sadiq            Electronic Data Systems
 Adi Sakala             IONA Technologies
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 William Stumbo         Xerox
 Sandra Swearingen      U.S. Department of Defense, U.S. Air Force
 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 
 Dan Kulp               IONA 
 Michael Mahan          Nokia
 Pallavi Malu           Intel 
 Michael Mealling       Verisign 
 Dale Moberg            Cyclone Commerce 
 Johan Pauhlsson        L'Echangeur
 Jochen Ruetschlin      DaimlerChrysler Research and Technology 
 Krishna Sankar         Cisco Systems 
 Daniel Schutzer        Citigroup 
 Dave Solo              Citigroup

Absent:
 Mike Ballantyne        Electronic Data Systems
 Mike Davoren           W. W. Grainger
 Youenn Fablet          Canon
 Tom Jordahl            Macromedia
 Mike McHugh            W. W. Grainger
 Jean-Jacques Moreau    Canon
 Stefano Pugliani       Sun

Chair: Jonathan Marsh Scribe: DavidB

Contents

Agenda Items

Approval of minutes

Minutes approved.

Review of Action Items

Action Items: DONE [7] 2002.05.16 DavidB to find out how to get registration list.

DONE [8] 2002.05.16 Roberto to post revised extensibility proposal, annotations out, revised extension.

Usage Task Force

Sanjiva: The document is out. Two weeks have gone by. The last telecon was organizational. I hope something will happen today.

Jonathan: Waqar also sent another draft of usage scenarios.
... Should we publish it now? Discuss it more at F2F? Hold off?

Waqar: I saw the use case doc from the Arch group and it contained a lot of the use cases that we have, and i added them.
... How will that synchronization take place?

JM: That's up to us.

JeffM: I think we should publish it with a disclaimer saying that it is the current state and we're working with the Arch group on it.

JM: Any objections to publishing the usage scenario doc with a note that JeffM describes?

Arthur: Has the revision included the updates?

Waqar: I made a number of updates, but it didn't incorporate all. Should we discuss the ones that were omitted?
... I incorporated the editorial comments, but not all of the more substantive things, because some were not clear.
... I've asked for clarification, but haven't yet received much feedback. So I didn't know what to do about it.
... I was hoping that it would be reviewed and I would get more feedback.

Arthur: There was nothing that i strongly objected to. My comments were mostly suggestions and clarifications. I have no objections to publishing.

JM: With no other objections noted, let's go ahead and publish it.
... Eventually the usage scenarios will migrate to the Arch group, and this group will only have specific use cases.
... That transition may be a little awkward.

Sandeep: The other good thing about the other group taking it up is that the task force is pretty dedicated, so I think theiry'll do a better job than we were able to do.

Philippe: I'd like to sync the status with the one we included in the requirements doc, and I'm not sure if I should modify that without the agreement of the WG.

JM: Anyone want to review Philippe's edits before we publish it?

(None noted)

JM: We'll go ahead then.

ACTION: Philippe to update status section of the requirement's doc

ACTION: Philippe, Jonathan, Waqar to work on getting the usage scenarios published

Overloaded Operations

JM: THere was an issue from Joyce about overloaded methods.

Keith: I think we should discuss it.
... I Don't like the term "overloaded methods" because WSDL is not exposing methods directly.
... They are "operations".

JeffM: I Don't think it matters if we call them "methods" or "operations".

DavidB: I suggest we call them "operations".

JeffM: Now let's talk about the semantics.

JeffM: The issue is that WSDL currently allows overloaded operations; the question is whether we should disallow them.

Joyce: I propose that we should disallow overloading.

DavidB: I support that also. I think it is clearer to have different names for things.

Arthur: It also may have server implications, as you must decide which method to invoke.

Adi: I agree.

JeffM: It also saves us from deciding when two parameter types are different, then you can overload.

JeffM: Is anyone in favor of overloaded operations?

(Silence)

JM: THe sentiment of this group is to disallow overloaded operations.

Kevin: Can someone summarize what is the problem of overloading?

JeffM: One problem is that you must decide whether parameter types are different, and therefore the two operations can be overloaded.
... (Couldn't keep up with typing the other reasons)
... Another problem is that it makes the mapping to language methods more difficult. YOu might need to do somethign like name mangling (from C++).

Kevin: Sounds fine with me to take the feature out, but since it was in WSDL 1.1, we should document the reasons for dropping it.

ACTION: JeffM to write up rationale for dropping operation overloading.

Can one-way operations return faults?

JM: Another issue is whether one-way operations can return fault or not.

JeffS: It seems that people were asking maybe for a new kind of message exchange pattern.

JM: WSDL 1.1 is pretty clear that a one-way doesn't have a fault.

JeffM: Where would the fault go?

JeffS: We're talking about adding a different MEP, not changing one-way, but adding a new MEP that has an input, no output, and a fault.

DavidB: It also raises the question of whether faults should be treated separately from outputs.

Sanjiva: Can you clarify what kind of fault you mean?
... i.e, app level or middleware level faults?
... But if you Don't get a fault, then it means your operation succeeded.
... So it isn't one-way, it's two-way with an empty output.

Prasad: It's an app level thing.
... It depends on your framework.

Keith: How would this be handled over HTTP?

Prasad: I guess it woudl be a Soap fault.

Keith: Because typically you get a 202 now, i.e., "accepted", which makes sense.
... because the incoming msg will be processed.

Prasad: The problem with the current approach is that you get either a 200 ok or you get a fault.

Keith: But that means I need to do the business processing to decide whether to return a 202 or a 500.

Prasad: This is a common business need. You want to know if something went wrong, but you Don't need to hear back anything if all is ok.

Adi: Why do we need another message pattern?

DavidB: Would there be a problem if the client gets back a message saying that all is ok, and ignores it?

Prasad: But I Don't want to get back too many "ok" responses that I must ignore.

JeffS: It sounds like you want a "Nack" model (negative ack).

Adi: If we consider this case, then we also need to consider it for the Notification case.

JeffM: Can't one-way's return faults?

Prasad: No, that's why we're talking about it.

JM: Suppose I have a subscripion svc, and a new satellite image is pushed to me every 3 hours. And if the data is not available, should I get a fault instead?

DavidB: It seems like the question is whether faults are needed at all for app level issues.

JM: It sounds like we have a better understanding of the issue. Let's continue the discussion on email.
... I suggest that we close the current issue, and have Prasad open a new issue re-titled "Negative Acknowledgement"

Prasad: Let's just rename it.

ACTION: Prasad, JeffS close the current issue, and have Prasad open a new issue re-titled "Negative Acknowledgement"

GlenD: Are MEP's hard coded in the spec, or can they be extended through extensibility.

JeffS: Hard coded.

DavidB: If they are extensible then you're getting into the topic of workflow.

ACTION: GlenD to post email adding an issue: Are MEP's hard coded in the spec, or can they be extended through extensibility?

Kevin: I notice we have two issue lists. Sanjiva's and Jean-Jaque's. Are they synced?

JM: No.

Philippe: Is MEP an architecture issue? Soap defines one, and we define one also.
... So should it go to the ARch group?

JM: We need to clarify the issue first.

Extensibility Proposal

Roberto: My proposal was an adaptation of a previous one. It is separated from the "annotations" proposal.
... For annotations there should be a very simple processing model. The hard thing to design is language extensions.

Igor: I was trying to look at two of the proposals. The difference seems to be the ability to include somethign from an arbitrary namespace.

Roberto: There are a couple of differences.
... I got rid of the architected extensions.

JM: SO you'd have to have a WSDL required or WSDL extension element.

Roberto: Not necessarily.

JM: So if I start reading a WSDL doc I can tell when i reach the extension mark whether this doc will have some third-party binding info.

Roberto: Right, for anythign optional, you can't tell it beforehand.

JM: And the other difference was the mechanism for indicating what was required.
... We need to define the inheritance of what's "required".

JM: Two key difference: (1) I can't tell from looking at the first part of the doc whether there is an extension that may be required.

Roberto: The difference is basically at the top element.

JM: Any other opinions about whether we need both WSDL required and a top level element?

JeffS: It feels like the extra WSDL extension that you're defining is really about the architected extension.
... I lost the motivation for the more sophisticated mechanism.
... I clearly understand allowing any/lax.
... But i'm missing the motivation for the WSDL:Extension.

Roberto: A language can require on a processor the use of rules that are global. The processor may need to know beforehand.
... To avoid backtracking during processing.

JeffS: To allow a one-pass processing model?

Roberto: If you're defining an extension, then you Don't want to have to label every occurrence as "required".

JM: It seems like the extension element is more convenient. But do you still need the "required" attribute?

Sanjiva: It's nice to have the info up front.

Roberto: If we get rid of the "reqiured" attribute, then suppose I want an optional extension that has a global attribute. How would I do it?

JM: It sounds like we should merge my proposal and Roberto's by removing the clause 5.d.
... ANd in my schema we would call out the Soap binding namespace.
... And we keep the required attribute also.

Roberto: And in section 4 of mine, it seems that we are talking about changing that to turn off required.
... There's another point also, in section 5.c. (incorrectly called 5.b.).
... I think if we were to write a similar clause for annotations we would write "a processor MAY...".
... So I can be optimistic that the processor will actually do somethign with it.
... If we have annotations along the line of the previous version, then the processor would not HAVE to do anything with it.

JM: ANd specifically processing of an annotation should not result in any different behavior for the rest of the document.

Roberto: But for optional extensions you SHOULD do something with it.

JM: SHould that go into the spec?

Roberto: Yes.

JeffS: I think we can boil it down to saying whether you MUST or MUST NOT do something with it.

Roberto: Ok.

ACTION: Roberto to take another round at updating his extensibility proposal

[Meeting adjourned]

Summary of Action Items

ACTION: GlenD to post email adding an issue: Are MEP's hard coded in the spec, or can they be extended through extensibility?
ACTION: JeffM to write up rationale for dropping operation overloading.
ACTION: Philippe to update status section of the requirement's doc
ACTION: Philippe, Jonathan, Waqar to work on getting the usage scenarios published
ACTION: Prasad, JeffS close the current issue, and have Prasad open a new issue re-titled "Negative Acknowledgement"
ACTION: Roberto to take another round at updating his extensibility proposal
Valid HTML 4.0! David Booth
dbooth@w3.org
$Date: 2002/02/19 16:35:31 $