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