W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2002

Minutes October 03, 2002 WS Desc Telcon

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Sat, 05 Oct 2002 09:52:04 -0700
Message-ID: <3D9F18B4.5010202@webmethods.com>
To: www-ws-desc@w3.org, jmarsh@microsoft.com


Web Services Description Working Group
2002-10-03 conference call minutes.

Present: 

David Booth		W3C
Allen Brookes   	Rogue Wave Software    
Roberto Chinnici	Sun Microsystems
Glen Daniels		Macromedia
Youenn Fablet		Canon
Martin Gudgin		Microsoft
Sandeep Kumar		Cisco Systems
Philippe Le Hégaret    	W3C
Amelia Lewis           	TIBCO
Kevin Canyang Liu	SAP
Jonathan Marsh		Chair (Microsoft)
Dale Moberg        	Cyclone Commerce
Jean-Jacques Moreau   	Canon
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
Jerry Thrasher         	Lexmark
William Vambenepe     	Hewlett-Packard
Sanjiva Weerawarana   	IBM
Joyce Yang             	Oracle
Prasad Yendluri        	webMethods, Inc.

Regrets:

Dietmar Gaertner	Software AG
Steve Graham         	Global Grid Forum
Tom Jordahl            	Macromedia
Steve Lind           	AT&T
Jeff Mischkinsky       	Oracle
Don Wright             	Lexmark
Barbara Zengler      	DaimlerChrysler Research and Technology


-------------------------------------------------------------------
Agenda

1.  Assign scribe
2.  Approval of minutes of Sept 26 telcon
3.  Review of Action items
4.  FTF planning
5.  Requirements
6.  New Issues
  	(none)
7.  Porttype inheritance.
8.  Rationale for dropping the <soap:body use=...> attribute
9.  BindingType proposal from Kevin
	Awaiting further work on Part 2 AM.
10. A slice at a proposal for SOAP features/properties in WSDL   
11. Issue 2: SOAPAction has been deprecated, as of SOAP 1.2
12. Issue 28: transport='uri'
13. HTTP Binding Issues 
14. Issue 25: Interaction between W3C XML Schema and SOAP Data Model 

-------------------------------------------------------------------
1.  Assign scribe
    Prasad Yendluri

-------------------------------------------------------------------
2.  Approval of minutes of Sept 26 telcon
	Approved

-------------------------------------------------------------------
3.  Review of Action items

DONE   	 2002-07-21: Don Mullen to write up an issue on making the 
                     transport attribute match the SOAP binding 
                     framework. 
PENDING  2002-09-09: Sanjiva to redo part 3.2 of his binding proposal.
			SW: Dependent on resolution of serviceType portType 
                            inheritance issue.
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).
DONE     2002-09-10: Steve and Gudge to write up the portType extensibility
                     proposal.
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.
                      MG: Its taking more shape in my head.
RETIRED  2002-09-11: Sanjiva to describe out/out-in for pub-sub. [I
                     think this should be pub-sub _without_ out/out-in.]
			JM/SW: Retired. Same as 09-19 action item below..
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.
RETIRED  2002-09-19: Glen to draft SOAP last call comment on why
                     SOAPAction is not a "feature", and request the
                     ability to set arbitrary mime headers.
			  GD: First part (SOAPAction)should be retired, 
 			      the MIME headers part should be kept.
DONE     2002-09-26: Philippe to get Eric's comments
DONE     2002-09-26: Jeffrey to remove the word draft for req125
PENDING  2002-09-26: Jonathan to prepublish the req docs
PENDING  2002-09-26: Jacek to make a proposal for better describing 
                     the extensibility mechanism to support other 
                     languages

New Actions as of 2002-10-03
	 ACTION: JS to repond to comments on requirements doc.

-------------------------------------------------------------------
4.  FTF planning

JM: Limited success negotiating w/ Arch group on their requirements.
    But, negotiated with them to send out a poll on preferred locations
    and dates. Based on membership we have been doing two on east coast,
    one in Europe and one on west coast. It is time for one in west coast.
    Arthur offered to host in Torento. We will perhaps take it up when it 
    is a bit warmer. 

    I will send out a poll with an XML with options for people to fill in.

JM: Tech plenary in Boston. We are planning to meet then. WS-CG is
    coordinating with XML Activity to reduce number of overlaps.
    Out request to organizers of the Tech Plenary would be for the
    WS-Desc WG to meet first on Mon and Tue Mar 3rd & 4th. Arch group
    will meet on Thu & Fri. Arch may meet with I18n group.. 

    Any other groups we need to consider.. Dom? Philippe?

Philippe: DOM is meeting at the end of the week does not conflict with this.
JM: Most of the conflicts are out..

-------------------------------------------------------------------
5.  Requirements

JM: There was a thread started by Eric about the need to identify things like URI.
    Anything from the thread we need to reflect in our requirements? Or we can tranisition
    to an issue we can deal with in the document?
Philippe: The discussion was also on if we keep the requirement or not?
JM: We alredy decided to keep it. 
Philippe: One issue was do we have one scope or more than one scope as in WSDL 1.1.
JM: Make sure no QNames in WSDL document conflict?
Philippe: Exactly.
JM: We had an issue open on that 
MG: We resolved it the opposite way.
Philippe: WS-I basic profile confines QNames to be unique.
MG: I don't believe so.
KL: I recall we made that decision but I don't see it in the profile.
MG: We had a long discussion in london and I don't thik that is what we decided
PY: Profile/Issue resolution does not say that
JM: Ok that is indeterminite. We might as well start discussing now. One problem is XML schema
    middied the waters.
Philippe: DTD's have the same problem. One scope for elements, one for attributes etc.
SW: I am running into people who believe all naming should be based on URIs and others for QNames. 
    Is it within our scope to define QName to URI mapping to our QNames?
Philippe: I don't think it is up to us. TAG is working on it, XML Schema is working on it.
SW: Can't we define a mapping ourselves?
Philippe: XML Schema is also working on non-aligned univ. names. Which is another.. for qnames to URI.
JM: Its a way to identify things that are hard to identify in a schema, including anon types.
WS: I was thinking of a mapping scheme. Are you saying we can not put that into our spec as a preferred mapping?
AR: We define a media type for WSDL and you can define rules for fragment identifiers. That can disambiguate QNames.
    You can have binding fragment, portType fragment etc. Whatever thing has a QName you define a fragment 
    syntax to identify.
DB: The problem w/ any mapping is unless the names are unique, you are injecting new names into some one else's 
    namespace. You risk clashing w/ other names in that space.
SW: If the mapping takes into account the kinds of things
DB: The problem with that is, you are injecting new names into some one else's 
    namespace. Unless that namespace can somehow guarentee that it will not use 
    that name, you will potentially have a clash.
MG: Our spec does not require anything other than QName references. Context tells us what we are ref'ing to, 
    a portType, a binding, a message etc. It is only needed by things that are external to the WSDL.
DB: Yes, idea is to make WSDL partially understandable by things that don't have to understand everything about
    WSDL. Lot of tools want to do that. E.g. Google need not know everything about a web page. 
MG: Schema had the same problem. The solution they took was to put IDs on everything. 
    Why not use the same solution?
Philippe: We already have QNames. Why have two identifiers on same thing?
MG: Because QNames are not Unique. Schema aleady has non-unique QNames. We can not fix schema space problem
DB: We define WSDL spec. We can place additional constraints that XML schema does not.
JM: It will make difficult to use existing Schemas with WSDL.
Philippe: In practice people do make QNames unique.
DB: It is clear to me there is gain in having them unique.
MG: Schema needs to have separate symbol spaces because of elems and attrs. It goes back to XML 1.0.
Philippe: Making the same mistake as schema?
JM: We need to have a mpping scheme between URI and QName that takes into account addtl info 
    on which symbol space it comes from.
DB: We have to say the owner of the target nmspace would never create names that conflict with names created by the mapping.
MG: I don't think hash is legal (speaking of examples pasted into IRC)
SW: We should be careful that URI does not base it on location of the docuemnt. Otherwise it will relative to the 
    place the document is at.
MG: We can have multiple WSDLs w/ same targetNamespace
JM: We can go two ways. One uses XPointer compatible fragment scheme (defines media types). 
    Second is: use IDs like schema did. How many WSDL components one needs to point.
SW: So authors needs to pre-imagine what things they might want someone to point to?
Philippe: I thinks IDs is a bad idea. 
SW: ID is unique to the target namespace.
JM: ID is unique to the URI not target namespace.
JM: Can we nail down our decision tree on this.
DB: I still don't see the benefit to having them non-unique. Schema made a mistake.
MG: ???
JM: David is questioning why even if chema made a mistake, why do we have to follow suite?
MG: I think we should be consistent.
SW: In this case it seems consistecy causes grief.
SW: We want to enable people to refer to them w/o having this problem.
JS: Are trying to make sure people can reference in WSDL document; just the top level elements or more?
JM: Idealy to anything.
JS: I think we should let people to point to any part of a WSDL document.
SW: You can use XPointer and point to anything.
....
....
DB: Even if you define things in multiple symbol spaces using same names to 
    define two different things is not good.
MG: I don't disagree with what you just said. 
JM: It seems we are starting go in circles. We have couple of options we discussed.
     Who would like to pursue one of the options
AR: I will do it.
JM: Which direction are you in favor of going?
AR: I will look at the trade-offs. I am in favour of media type and fragment identifier. Simpler syntax than XPtr.
     I can clarify what the issues are.
JM: Anyone else wants to promote other approaches.
DB: Certainly one approach is to have QNames Unique.
MG: What URI would you use to assert the QName
DD: TAG is working a mapping scheme QName to URI.
JM: If we have unique QNames we might be able to use whatever the TAG develops
    That does not solve problem for schema component, if we want to navigate seemlessly
    identify schema or WSDL components.
SW: Our problem is to enable pointing into things within WSDL document. That does not
    include pointing into Schema.
MG: People might want to point into things within the types element.
SW: They can use XPtr or whatever schema decide for that.
JM: Arthur will start his off and we will make some progree.
JM: This conv. is under the agenda item of requirements. 
    We have some addt'l comments from Mike ?.. JS made some editorial
    changes based on that. Have you responded to that?
JS: Couple of places we made changes as that is what we meant. Other places comments are about
    fully being clear on what we meant. Our current interest is not getting the requirement
    doc perfect side by side. Re draft served its purpose and we should move on to solving 
    intersting design issues.
Philippe: Shoule we bring them fwd as issues on the Working Drfat?
JS: When we get comments, esp. if we put out a last version, it would be nice to respond
    to the comments (agree / disagree), if the responder pushes back it will come back to
    the WG. Jeffry may be you can take a pass at responding.
JS: I will take an action for next week.
ACTION: JS to repond to comments on requirements doc.

------------------------------------------------------------------
6. New Issues
(none)

-------------------------------------------------------------------
7.   Porttype inheritance.

JM: MG put fwd a proposal ..
MG: Steve observed it gets into portType aggregation. Doing at service level is fine. 
    We discussed at F2F in VA, and we concluded that it is not necessary at portType(?)
    If people think it is necessary we can modify the proposal accordingly.
SW: Thought Steve said he wanted multiple..
MG: I read it as him saying he is happy with listing mutiple portTypes in a service.
SW: In BP you may want to model Business Operations and lifecycle operations as separate 
    interfaces and publish it as a single interface though designed as two separate.
GD: I am not sure I agree but, all that info is still there if you have portType inheritance.
    E.g.Java has is similar. A class can implement as many interfces.
SW: Service is exactly class for me. So in Java, we are are going to force everyone to 
    inherit all interfaces into one interface and then implement it as a class?
GD: Service has already gone through binding. If you can not do aggregation until after then,
    it is not so great.
SW: I am not arguing against portType inheritance. I am saying portType inheritance 
    and losing ability to support multiple interfaces as a service are two different things.
    They should both be supported. 
DB: Are we distinguing bet. inheritance and aggregation?
MG: Not really
DB: There is more than one kind of inheritence.
AR: Do we want to force people to inherit all portTypes into a single portType and then
    implement the service.
SK: When you inherit interface you are also inheriting behavior.
Philippe: What about overloading?
MG: We disallowed operation overloading if that is what you are referring to.
Philippe: Even if it is coming from a diamond inheritance?
MG: According to current proposal it is a set.
SW: We can't think of it as operation aggregation as long as portType concept has a 
    basis property. It is saying I am not flattening the operations but recognize portTypes
    inherit.
MG: According to the prposal everything is flat.
SW: Then it is not inheritance at all. Why do we have a portType basis property.
MG: That is the mechanism to refrence other portTypes and bringing in operations.
SW: So given a WSDL model in portType I wouldn't be abe able to ask who are your super types?
MG: There is no need to do so. The portType has all the operations from hierachy and its own
    operations (in the derived components).
GD: There is no chain to walk up. portType is an abstract thing.
RC: portType component refers to its parent or a list of them.
AR: If you were to query which services impleted a portType, you would also get the services
    that inherited the portType.
DB: There are two kinds of inheritence: Diamond and Aggregation... Which one we want?
GD: I think diamond is the only option.
JM: Diamond is what is in Gudges's proposal.
GD: This includes the binding. I think binding is something that should be decided after what
    is all in the interface is determined. If you combine serviceTypes that include bindings
    into service that is a strange thing.
MG: Steve suggests since we have the basis attribute, you can do the aggregation at the 
    portType level or as Sanjiva suggests you can do the final aggregation down at the 
    service level.
JM: Is there anything beyond usability that would help us decide?
SK: People are talking of service as a clas. I consider service to be more of an application.
DB/GD: If you have diamond what if an operation w/ same name is both interface you 
    inherit from?
MG: Curtrent proposal says you can not have that. It is illegal to have operations w/ same
    name within the scope. There is some discussion on the list on this.
SW: This is make it impossible to design portTypes in isolation and then combine them.
MG: We need a way to make unique name out of an operation name. We may need to make op names
     QNames.
DB: If the problem go away if we use aggregation style instead of diamond?
GD: What does it mean in terms of WSDL? It is not like two implementations are coming
    from two different classes. The distinction between diamong/aggr. inheritance 
    does not help here. We have the same problem in both cases.
JM: We are winding down on time. We have several proposals.  Do we want to make a decision
    or get a proposal that services can inherit from multiple portTypes..
MG: That is a straight-fwd change. I can make a new proposal with that change.
ACTION: Gudge to amke a new proposal with services inheriting from multiple portTypes
SW: Do we have time to do ???
SW: Before we decide to commit on portType inheritance we need to finish the detailed
    proposal. The second proposal/option of Gudge of multiple bindings to support inheritance 
    amounts to inheritence of implementation. That would be bad in my mind
MG: Why does it introduce implementation inheritence ?
SW: To me, binding conceptualy describes implemtation of an interface. This is a major change
     we need to think this through before we make a commitment.
JM: That is MG's option D. So we should examine that thread. This conversation / thread is 
    still alive.
JM: Everything I have on the agenda is dependent on some other action or some other issue,
    except Glen's proposal we discussed last week. We decided to pursue on email but, 
    I have not seen anything. Try and follow-up on that topic. I will add it to the agenda
    next week. 
JM: Anything else before we adjurn? Ok thank you all..


-------------------------------------------------------------------- 
Call Adjourned

--------------------------------------------------------------------
	Scribe: Prasad Yendluri
Received on Saturday, 5 October 2002 12:54:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT