See also: IRC log
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
Action Items: DONE  2002.05.16 DavidB to find out how to get registration list.DONE  2002.05.16 Roberto to post revised extensibility proposal, annotations out, revised extension.
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.
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?
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?
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.
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
JM: THere was an issue from Joyce about overloaded methods.Keith: I think we should discuss it.
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.
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.
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.
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.
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.
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?
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.
Roberto: There are a couple of differences.
... I got rid of the architected extensions.
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.
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.
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.
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.
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]