- From: <Barbara.Zengler@daimlerchrysler.com>
- Date: 2002年10月17日 08:48:00 +0200
- To: <www-ws-desc@w3.org>, <jmarsh@microsoft.com>
- Message-ID: <0057440035825804000002L442*@MHS>
Web Services Description Working Group 2002年10月10日 meeting minutes Attendance Present: Mike Ballantyne Electronic Data Systems David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Youenn Fablet Canon Dietmar Gaertner Software AG Martin Gudgin Microsoft Jacek Kopecky Systinet Sandeep Kumar Cisco Systems Philippe Le H馮aret W3C Amelia Lewis TIBCO Steve Lind AT&T Kevin Canyang Liu SAP Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle Dale Moberg Cyclone Commerce Jean-Jacques Moreau Canon Don Mullen Tibco Arthur Ryman IBM Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates William Stumbo Xerox Jerry Thrasher Lexmark Steve Tuecke Global Grid Forum William Vambenepe Hewlett-Packard Don Wright Lexmark Joyce Yang Oracle Prasad Yendluri webMethods, Inc. Barbara Zengler DaimlerChrysler Research and Technology Regrets: Steve Graham Global Grid Forum ------------------------------------------------------------------- Agenda 1. Assign scribe. 2. Approval of minutes of Oct 3 telcon 3. Review of Action items. 4. FTF planning: 5. Requirements 6. New Issues 7. Porttype inheritance. 8. Import/include 9. Identification of a Service 10. Rationale for dropping the <soap:body use=...> attribute 11. BindingType proposal from Kevin 12. A slice at a proposal for SOAP features/properties in WSDL. Canon's change requests 13. Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 14. Issue 28: transport='uri' 15. HTTP Binding Issues 16. Issue 25: Interaction between W3C XML Schema and SOAP Data Model ------------------------------------------------------------------- 1. Assign scribe Barbara Zengler ------------------------------------------------------------------- 2. Approval of minutes of Sept 26 telcon Approved. new ACTION: Arthur to propose a way to assign a URI reference to any element in WSDL (related to Requirement 120) ------------------------------------------------------------------- 3. Review of Action items. PENDING 2002年09月09日: Sanjiva to redo part 3.2 of his binding proposal. DONE 2002年09月09日: Gudge to check whether there is already an issue against Part 2: can you define different encodingStyles for different children of soap:Body (message parts). PENDING 2002年09月10日: Sanjiva to produce a proposal for equivalence of (at least) top-level components in the next couple of weeks. PENDING 2002年09月10日: Gudge; jeffsch; roberto et al to write proposal [to remove message and replace with complexType.] PENDING 2002年09月10日: Gudge to provide summary of using xml schema to wrap other type systems at an appropriate level of abstraction. PENDING 2002年09月11日: Jeffrey and Don define TCP binding. PENDING 2002年09月19日: Joyce, Sandeep, Igor, Steve T, Sanjiva, Adi, Roberto, Amy to form a task force to prepare presenation about adding pub/sub in a first class manner to WSDL 1.2. PENDING 2002年09月19日: Sanjiva to write a Java binding. SKIPPED 2002年09月19日: Glen to draft SOAP last call comment requesting the ability to set arbitrary mime headers. PENDING 2002年09月26日: Jonathan to prepublish the req docs DONE 2002年09月26日: Jacek to make a proposal for better describing the extensibility mechanism to support other languages PENDING 2002年10月03日: Jeffrey to respond to comments on the Requirements document. DONE 2002年10月03日: Gudge to revise the portType proposal with services inheriting from multiple portTypes -------------------------------------------------------------------- 4. FTF planning Registration for the November meeting closes 2002年10月11日: Please register. Logistics for November F2F: http://www.w3.org/2002/ws/desc/2/04/f2fNovLogistics.html Web Services Architecture and Description Working Groups F2F Meetings: Nov 11, 2002 - Nov 15, 2002 (cutoff:Oct 11, 2002) The January F2F proposal is sent out: Please vote. There is no agenda for the F2F yet. -------------------------------------------------------------------- 5. Requirements [6] Additional comments [8] Jeffrey is expected to bring forward comments. -------------------------------------------------------------------- 6. New Issues Typos in section 2.5 [9] The issues are to be taken into account by the editors. -------------------------------------------------------------------- 7. Porttype inheritance Discussion about outstanding issue: Name collision -Making Operations Top Level Constructs and making their names not Qnames but NCNames could be one way of solving the problem -Name Collision is showing up in section 2.5.1, constraint : All operations have unique names within the port type. An operation can be uniquely identified within the port type where it is declared. -How do you guarantee that all the messages arriving at a port are unique -> same problem at another layer. Right now it is possible to write a description and to have that problem . What level do we want to deal with it? Maybe at the binding level? -The cleanest approach would be at the top level. -Promotion of an operation would be easy. -When you want to build higher level tools this is a problem. -Jacek: Making operations first class citizens of WSDL only makes sense if they are shared by port types. I am not sure if we want operations to be shared by port type. With inheritance you inherit all the operations. -Gudge: Reuse is a reason. The other reason is to want a unique name -> strong enough to make it top level. -If we made operations first class only because of allowing them to have unique names, that seems to promote reuse of operations. Not sure if thats a good idea. -It is not a problem if the people are aware to do so. -This is not necessarily so. -Port types become an abstraction of grouping that way. -2 issues identified: - the proposal gudge brought forward - and the one discussed here -Multiple port types of a service is a seperate issue -Jonathan: Do we want to accept both proposals? Roll them together in a grand proposal and think about it another week? -Arthur: What about binding. Could two port types have different bindings? Or is the binding also at operation level? -Gudge: No, the binding is at port type level -When we make operations first class: What is publicly visible? Are we going to consider this? -Jacek: The proposal removes the service type. was that the intention? -Gudge: Yes. -Igor: If we make operations first class citizens, can i have only one operation for port types then? -Gudge: Yes. For a given target namespace, all operation names would have to be unique. -Jeff: How much value is provided by making operation top level instead of message? Aggregated operation, where you put 2 messages together. But with a one-way-message ? People use a lot of one way messages. -Why doesn't uniqueness of a message help? -Arthur: Doesn't portTypeName/operationName identify it? -Gudge: Yes, it does and we could go that way, I'm just not sure we want to get into what are essentially 'sub namespaces' -Igor: to Arthur: if you have A:get returns tA and B:get returns tB then it is a problem, even though you could identify those ops. Making ops first class resolves it. -Roberto: How would this interact with Glen's proposal? Right now: description is identifying signature. same signature, different features ... -Gudge: I don't see that it changes anything. -Roberto: Different features have to be defined twice. Global abstraction for that particular signature. You think conceptually, you can identify. But in reality you have to identify features. -Gudge: I am not sure I see why where we actually stick operations in terms of syntactic placement affects how you would mix in features. -Jacek: what's a signature (aside from the binding level) ? -What does making the operation global do semantically? -Gudge: Just give them unique names. -Making operations global will have consequences. We should take a look at some of the potential consequences before committing one way or the other. -Gudge: I think we have greater progress if we take the two issues together. -Jeff: The feature issue is seperate from that. -Jean-Jaques: Seperately. -Gudge: When we see that proposal we can see what the impact is. -Jonathan: Should we ask gudge to roll the promotion of operations to the top level into his inheritance proposal and have another week or more to work at it? Perhaps as Glen is doing further work on the feature proposal he can analyze this further. Roberto could help him. Does that sound reasonable? -Yes. -Question for Arthur: Sanjiva was enthusiac about the port type thing, do you know what his position is? -Arthur: IBM is ok with this. another thing we agreed is that we didn't like the name port type ;) We wanted to change this to interface ;) -We should collect all the naming changes and work at them at once. ACTION: Gudge to roll in the current changes (port type inheritance) into the main branch, adding an issue that we need to resolve the name issue and also the issue for promoting operations to the top level. ACTION: Roberto to see how this might affect the feature proposal. Glen to review this. -------------------------------------------------------------------- 8. Import/include Discussion about import: -Jonathan: Details about wsdl:import were missing. There was a lot of discussion on this. Import only allows you to import something in another namespace. Schema solves this by providing include (to import sth from the same namespace). The proposal is to have wsdl:include. -Arthur: Schema doesn't have to declare a namespace. Cheap way of re-using definitions. -Gudge: Our target namespace is mandatory. -Arthur: then it sounds fine to me. Discussion about the location attribute: -You need the location when you have two things that you want to keep seperate. -Gudge: yes, that's right. -Amy: There are a number of issues that can be avoided when the only way of aquiring information is via that location. -Roberto: I agree with arthur, this may ba a interoperability problem. -A hint is even worse, like in schema. -Gudge: I agree that if there is no location that might be an interop problem. -Should we put a note in spec that for interop it is recommended that you do use the location attribute and it is only optional for more closed systems... -It doesnt seem inconsistent with schema to recommend this. -Alewis: +1 to note recommending best practice as well. -Jeff: +1 for matching existing models where appropriate -Proposal would be to add wsdl:include as in xsd, make the location on import optional. -Arthur: I want to review that with Sanjiva. -Jonathan: Ok. So let's put it on the agenda for next time as a proposed resolution. PROPOSED RESOLUTION: Add wsdl:include, the use of the location attribute is recommended best practice. -------------------------------------------------------------------- Call Adjourned -------------------------------------------------------------------- Scribe: Barbara Zengler
Received on Thursday, 17 October 2002 02:48:42 UTC