Web Services Description Working Group 2003-02-06 meeting minutes Attendance Present: Erik Ackerman Lexmark Mike Ballantyne Electronic Data Systems David Booth W3C Allen Brookes Rogue Wave Software Glen Daniels Macromedia Youenn Fablet Canon Martin Gudgin Microsoft Tom Jordahl Macromedia Jacek Kopecky Systinet Sandeep Kumar Cisco Systems Philippe Le Hégaret W3C Amelia Lewis TIBCO Steve Lind AT&T Kevin Canyang Liu SAP Lily Liu webMethods Jonathan Marsh Chair (Microsoft) Dale Moberg Cyclone Commerce Don Mullen Tibco Arthur Ryman IBM Adi Sakala IONA Technologies Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates William Stumbo Xerox Jerry Thrasher Lexmark Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Barbara Zengler DaimlerChrysler Research and Technology Regrets: Roberto Chinnici Sun Microsystems Dietmar Gaertner Software AG Steve Graham Global Grid Forum Jean-Jacques Moreau Canon William Vambenepe Hewlett-Packard Steven White SeeBeyond Prasad Yendluri webMethods, Inc. Agenda 1. Assign scribe. 2. Approval of minutes of Jan 30 telcon 3. Review of Action items. 4. Administrivia 5. New Issues. 6. Service definition conflicts 7. Operation name uniqueness. 8. Requirements. FTF resolutions. 9. Properties and features. 10. Removing message. 11. HTTP Binding Issues 12. BindingType proposal from Kevin 13. Issue 28: transport='uri' 14. Issue 2 -------------------------------------------------------------------- 1. Assign scribe. Barbara Zengler -------------------------------------------------------------------- 2. Approval of minutes of Jan 30 telcon [.1] Approved. -------------------------------------------------------------------- 3. Review of Action items [.1]. DONE 2002-11-21: Jonathan to refer R120 text to TAG, referencing TAG issue fragmentin XML-28, when that text appears in the draft. PENDING 2003-01-16: Sanjiva to explain why naming faults is unnecessary DONE 2003-01-20: Glen, Amy, Youenn, Sanjiva, JJM to form a TF on comparing the features/properties and existing extensibility mechanisms, to illustrate feature/property rationale, use cases, and examples. DONE [.2] 2003-01-21: Umit to send Gudge and Roberto a knarly XML Schema type example. PENDING 2003-01-21: Roberto and gudge to create a branch and work up a binding proposal based on referencing type systems directly from operation components. (Umit's example, Sanjiva's example, WSDL 1.1 example, and others.) PENDING 2003-01-30: Jacek to write up text on SOAP response MEP after Gudge and Jeffrey send their proposal for request/response MEP. DONE [.3] 2003-01-30: Jonathan to organize Features & Properties dial-in number; invite Arch group. PENDING 2003-01-30: Gudge to check that we have an issue regarding being able to specify the verb on a per operation basis. DONE [.4]? 2003-01-30: Sandeep to follow-up with Dave Orchard and people in WSA and report back whether he can spend cycles on this doc. DONE [.5] 2003-01-30: Gudge to produce HTML version of operation name Branch. DONE 2003-01-30: Gudge to mark issue-extensible-message-exchange- patterns as closed. -------------------------------------------------------------------- 4. Administrivia a. Register for March FTF [.1] b. Properties & Features Task Force administration a. The hotel reservation has been extended. If you haven't registered yet, please register. b. -JM: The Task Force had a call on Monday. Some ppl got rejected by the telephone brigde. Discussions were on the mailing list. There is a separate mailing list with an archive. -Philippe: The mailing list is writable by anyone. -JM: If people are making public comments, we should forward the comments and redirect the threads on main list. The main outcome was a decision to document the usage scenarios and to show how the properties and features mechanism added to WSDL would simplify those scenarios. The TF came up with list of initial scenarios they would work on. What are those scenarios? -Glen: I remember most of them. We want to talk about features (why they were put into soap), security, doing a request-response over a one way transport protocol, a policies based example, a feature put in a header, about asymmetric features (things that might reuse different specs), about 2 features that use the same property set. -JM: As far as what we're bringing out of the TF to the WG, motivational material on Usage scenarios, will we have some initial material for the F2F in camridge? -Glen: I think so. The next goal is to schedule a call, things will become clearer then. -JM: Would it be worthwile to spend some time now to try and find a time for a telcon? -Glen: No. -JM: Ok, then we will do that on the mailing list and find a convenient time. Anything else? Does someone want to be added to the mailing list? -Philippe: Please use the normal subscribe mechanism, there is a link somewhere. -Glen: Is this link going to be published on wsd page? -Philippe: Yes. -JM: Duration of TF should not extend a few months, I thought of 60 days or something like that. However, if it is useful after the initial deliverables, then we can keep it going. The XPath TF has been a standing group for years and it does work. ------------------------------------------------------------------ 5. New Issues. Merged issues list [.1]. -JM: I didn't notice any new issues. -?: The current specification points to the XML fragment syntax in the Media Type registration for WSDL, on fragment syntax (scribe's comment: Appendix A, A.1 Registration). I thought we would propose a WSDL fragment syntax. -JM: I had an action item to refer to the TAG, this was missing in the public draft. I found evidence that the action item had been dropped by the editors. Gudge proposes a fragment syntax. That fragment syntax is intended to be used in conjunction with namespace name. There is no guarantee that the namespace name points to any document. What is the media type? Is it WSDL? -Arthur: I thought we would define this for the WSDL syntax. -?: Which namespace are we talking about? -Steve: We are going to use it if there is something at the end of the target namespace. I am not sure if we intend to use it in our own spec. -?: In our spec it would be in the Appendix. -Arthur: In the Mime type registration there is a description of fragment syntax. -JM: We use a simplified fragment syntax for use with MIME. We use a fragment syntax with a target namespace URI to identify components. This use was illegal, I had an action item to raise this with the TAG. Does anyone have problems with adding this as an issue to the spec? -Gudge: Is there a problem referring to a normative thing? Appendix a is normative, Appendix c is non-normative. -JM: I think there is and I think we can sort that out as an editorial issue. -Gudge: Ok. -JM: If that's ok with everybody else. -Gudge: What about "Appendix c points to the XPointer framework"..? -?: What would it mean to have the fragment identifier non-normative? -JM: That's what were trying to fix. It is an editorial improvement that Gudge would make to make it normative. The fragment identifier syntax would be normative. The modification that was just proposed by gudge: it is legal to have fragment identifiers compatible with the XPointer framework, but we don't say that we actually support the XPointer framework. -Gudge: I am not sure whether you want back in media type registration. -JM: It wouldn't be in the non-normative part. -Gudge: ok. -JM: If you just point to Arthur's new fragment scheme we don't say normatively ? -Gudge: So, either "identical to XPointer" or "fragment identifier syntax as described in appendix c"? -JM: Does anybody have objections to accepting the proposal? There were no objections, the proposal was accepted. ------------------------------------------------------------------ 6. Service definition conflicts [.1] -JM: The Architecture Group has discovered that their glossary and the description requirements have two definitions of service and web service. i guess we should start with web service. The Architecture Group has a definition I think originally we have synchronized but it sounds like they have moved on a little bit. The 1st change is : We say a Web Service has an interface and a binding that are capable of being described in XML. The Architecture Group says, public interfaces are defined and described using XML. I would propose that we accept the definition for the requirements and link to that definition. Does anybody think ours is better than the Architecture Group's definition? -?: The right thing to do is to follow their definition. -?: We will have to do that. -JM: any objections to using their definition? There were no objections. -JM: Next question: We should update our editor's draft with that. We should link to that definition since there is a glossary now. Any concerns about that? -JM: No concerns. Objections? -JM: ok. so let's close that. NEW ACTION: Jeffrey to synchronize the definitions by referencing the terms in the glossary. -JM: We have a collection of endpoints called a service. The Architecture Group has a generic definition of a service: a component performing a task. -David: We might adress to adorn the word service or prefix it with sth, like wsdlservice if we use it in the spec in order to clarify that we mean that specific meaning. The Architecture Group needs to talk about it in a general way. It would be hard for them to avoid the use of "service", the Architecture Group has an entirely reconciled definition of Web Service. -JM: So, is it appropriate for us to change our terminology on order to avoid a clash? Do we postpone it? -David: I don't see this issue going away - we need to refer to a specific thing. It would be in our interest to adopt a specific term like wsdlservice or sth like that. -JM: The proposal is to change our term to something like wsdlservice. Anyone with a better term/idea? any objections? -JM: No objections. We change the term service to wsdlservice. Anybody who can invent a better term, let us know. RESOLUTION: Change the term service to wsdlservice. -------------------------------------------------------------------- 7. Operation name uniqueness. -JM: Last week we had looked ad Gudge's draft. Nobody had a significant comment, it wasn't clear who had reviewed it and there were absent people, especially Sanjiva. I would like to take a vote on it. Now, a question for Sanjiva, you have some questions on it and suggested that we come back and allow operator overloading again? -Sanjiva: Yes, we should reconsider overloading. Operations need to be global. I would say this dicussion is not yet complete. -JM: We also talked about it at the F2F, Steve Graham raised the issue. We worked out a proposal he was comfortable with. -Sanjiva: It is no problem to say every port type has to be in its own namespace. -Philippe: You do not force people to use different namespaces. If someone else is using the same namespace as you you are in trouble. -Sanjiva: No Philippe, you cannot guarantee that someone inherits a port type from your namespace. -Gudge: We did explore all the axis of the design space in phoenix, incl. overloading and some other approaches to deal with the uniqueness problem, the only problem was the one that is on the table. -Sanjiva wants to understand why this is the best proposal. -Sanjiva: Can somebody tell me why overloading is a problem? We can do this by email... Why can we not introduce it again? We eliminated it because we found that it was not a widely used capability. Then we went back in port type inheritance. -?: There were several reasons why whe eliminated overloading. -JM: Well, I am not sure how to proceed. We would like Sanjiva to agree that our solution is good and that hasn't happened yet. Normally we would continue the discussion. Is it of benefit for the WG to postpone it? -Sanjiva: Operator overloading is one way to solve the problem. -Jeffrey: Is there a specific problem? -?: Does this stand in the way of other things we need to forward on or could this be postponed until the next Face-To-Face? -JM: The guys at WSI (scribe: ?) wanted a solution that they could point to. We committed that we would deal with that quickly. -Sanjiva: Inheritance allows you to have operations that are completely transparently overloaded without you having control over it. -Jack: Inheritance has brought a new light into it because it makes overloading much more likely. One of the issues against overloading was that nobody uses it. With inheritance this would no longer be true. -Jeffrey: We should scan the archives. -JM: Does anybody want to make a motion so that we call this vote now? -Sanjiva: Are you asking for a formal vote? -JM: Yes, I put it on the agenda. Would anybody object to cancelling the vote today? -Gudge: Would a week change a lot? -JM: People prefer us to get the right solution, not a fast one. -Sanjiva: I am a bit confused. We were used to do straw polls. Why would you want to take a formal vote? -JM: I am happy to make a strw poll. Let's take a straw poll. Should we go with the inheritance decicion out of the f2f or do people want to go with overloading? -?: I think the situaion now is different. We are abandoning soap encoding, messages are described with schemas. Do we have accurate schemas for the messages? Is the type of the input message enough to distinguish? -JM: Interesting observation. I want to go back to the straw poll Sanjiva wanted. -Sanjiva: No, i did not want it. -JM: Ok, i am not doing it. We continue the thread Sanjiva started and people take a look at that. Let's see where we are next week. -------------------------------------------------------------------- 8. Requirements [.1]. FTF resolutions [.2] 8a. DRAFT R129 "The description language SHOULD allow specifying the MIME media type of message content." 8b. DRAFT R130 "The WG SHOULD define components that may be used within Messages to refer to other WSDL components." 8c. Issue 71? [.3] - JM: We have resolutions from the f2f: add draft requirement R129. Do we want to accept that as a requirement of deny it? Should we add this requirement? -?: I think it's good. -JM: In the absence of any other information I guess this was a result of public comment by David Orchard. Does anybody have objections on removing the word draft? -JM: No. Ok, we will mark that as accepted. NEW REQUIREMENT R129: "The description language SHOULD allow specifying the MIME media type of message content." -JM: Draft R130: "The description language should define components that allow the use of other WSDL components." might be a better wording. -JM: Its not in our charter but I think this would fall through, a small thing, I think this is within our preview. Do we feel that this is a useful service to users to provide this, a standard element/xml syntax, to referring to ports? -Sanjiva: We will define a representation of what a port reference will be? -JM: I think so. Somebody had their own port reference elements in their own namespace, it would be nice to make this available in a modular fashion. -Sanjiva: Basically you can send XML serialization of those concepts within the WSDL message, right? -JM: I think so. This isn' t requirement of a description language. We can move it to our issues list, should we add an appendix that provides this construct. -?: It would not be a requirement but we may do it in the future. -JM: We have to decide whether or not we do it. We might have to liaise with other groups. It might be a lot of work. If there is a compelling majority we should do it. -?: Could we get more clarification? Was it discussed at the f2f. -Gudge: I am not sure if it was deeply understood at the f2f. It was discussed for only 20 minutes. It would be appropriate to clarify the wording. -Sanjiva: My only concern is it goes beyond description, it is more architecture. -JM: It is clearly sth related to our specification. We define ports, it is close to define port references. But do people care one way or the other? I may be useful -?: May i say something in favor? It seems that there are a lot of other specifications with similar concepts, and they might use a reference. -Sanjiva: I am ok with accepting it as a "should" requirement. -JM: This is a good time for a straw poll. Do we add a port reference type construct or not? STRAW POLL - Results: Yes: 8 No: 1 Abstained: 14 -JM: Most obstained, yes is second, one no. So I guess that means that I will put it in the requirements document as a should. NEW SHOULD REQUIREMENT R130: Add a port reference type construct. -JM: Issue 71. This is I guess an issue against the requirements document. Jeff, did you add this? -Jeff: Yes, I added this issue to the issues list. It is an issue against part 2. -JM: So this really is an issue against part 2, ok. Tthat's it. The rest is for the f2f. I am wondering if we should start taking up some of the soap binding issues that we can begin to discuss and deal with. We have been foussing on Part 1 for so long. Would it make sense to track some of the part 2 issues? -JM: We heard that maybe the http binding would be of interest to the community out there. Sanjiva wanted to mull it over (back in july). Should we go back to HTTP binding issues next week? There were new messages on the mailing list. I could send a summary, if somebody wants an action item to start discussion on that. -Sanjiva: I wanted to mull it over. I want to mention that we will have to do a binding for the SOAP response MEP. -Jack: I think the GET binding will not change the HTTP binding in any way. It should be in the SOAP binding completely. -JM: I am sorry I lost the thread there.I go ahead and send a message to get this going and take some time next week to talk about it. ACTION: Jonathan Marsh to send a summary about HTTP binding issues. -------------------------------------------------------------------- Call Adjourned -------------------------------------------------------------------- Scribe: Barbara Zengler