Minutes October 10, 2002 WS Desc Telcon

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égaret    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