- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 12 May 2003 10:26:10 -0700
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
Monday 12 May
--------------------------------------------------------
Present:
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Philippe Le Hégaret W3C
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Jean-Jacques Moreau Canon
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
09:20 Introductions and logistics
- Assignment of scribes
Mon AM: Sanjiva Weerawarana
Mon PM: Jeff Mischkinsky
Tue AM: William Vambenepe
Tue PM: Youenn Fablet
Wed PM: Jean-Jacques Moreau
--------------------------------------------------------
09:30 Publication plan
June Working Drafts (Part 1, Part 2, Part 3)
Discussion about what we should publish and when. Proposal to try to close most of part 1 before the next f2f .. try to get to last call before the end of summer. General consensus on doing that; JM will try to force our hand a bit to get to that point.
William wondered what may happen if we find problems with part1 while doing parts2/3.
Sanjiva claims that's unlikely, but at least in theory we can go back and change stuff
Understandability of the current draft specification (part 1). Discussion about whether the current structuring of abstract component model, the infoset model and then the mapping is the best approach. Proposal to add a "pseudo syntax" summary before the start of the infoset model.
[jeffsch: <interface name="xs:NCName" extends="list of xs:QName*"? ...>
<documentation />?
<operation />*
<feature />*
<property />*
...
</interface>
Proposal to add an instance example as well.
Arthur would prefer to use instance examples rather than a pseudo-syntax.
Someone needs to look into the possibility of generating the pseudo-syntax automatically instead of doing it by hand. Jonathan recommends that editors add the pseudo-syntax manually, and he will in parallel try to find a way to auto-gen that.
ACTION: Editors to add (non-normative) pseudo-syntax description of each component.
ACTION: Jonathan to work on auto generating pseudo-syntax
ACTION: Editors add more context to the specification - provide more descriptive wording to make it easier for someone to read the specification and to relate to Web services etc. before jumping into component-by-component descriptions.
--------------------------------------------------------
10:30 WSDL 1.1 binding for SOAP 1.2 [3].
- Do we envision a need for separate bindings for SOAP 1.1 and
SOAP 1.2, or do we think a parameterized binding is best?
[3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2003May/0002.html
Discussion of whether we should do it or bless it or do nothing.
[jeffsch: http://groups.yahoo.com/group/soapbuilders/files/soap12WSDL.htm]
There is already work-in-progress in the soapbuilders community to define a 1.2 binding. Axis' wsdl2java supports soap 1.2 with some kind of out-of-band flag w.r.t. wsdl. XMLP group has apparently come close to deciding that doing a soap1.2 binding for wsdl 1.1 is not their problem.
Glen notes that soap 1.2 has a version mismatch fault define to make interoperability easier.
JM to communicate back to CG:
.. 1. soapbuilders stuff: take that approach and just use that.
.. 2. out of band w.r.t. wsdl (ala axis)
.. 3. can live without wsdl help using version mismatch fault
ACTION: JM to take the above points to the XMLP/CG worlds and see what to do next.
A question is whether the industry is happy enough with a soapbuilders defined approach for a soap 1.2 binding. If so why define more process? If not, we can consider doing a note kind of thing. Glen volunteers to chat with soapbuilders and decide what to do.
ACTION: Glen to talk to SOAPBuilders about how to move forward on the SOAP 1.2 binding for WSDL 1.1.
--------------------------------------------------------
11:05 Break
11:20 Proposal for restricting a service to a single interface [4].
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0069.html
TOPIC restricting a service to a single interface
[Sanjiva summarizes the situation]
Sanjiva: Proposal: all endpoints inside the service element will support
the same interface. (that would also do some simplifications
in the binding btw). You do loose functionality with regards to
what we have now... At IBM, we haven't mush use of more than
one interface per service. WSDL is describing _one_ service.
Glen: let's taxonomize as roberto did:
1. a thing that represents the implementation of a particular
interface at one or more places.
2. a larger level thing where there is more than interface where
they are somehow related and offered "together".
[Umit draws on the whiteboard:
2 interfaces I1, I2, implemented on 4 endpoints E1, E2 for I1,
E3, E4 for I2. Having E1, E2, E3, E4 in one component is the
current statu quo. We could have one service S1 for E1, E2
and S2 for E3, E4. With a relationship between S1 and S2?
see: http://www.w3.org/2003/05/wsd-pics/dcp_4973.jpg]
Jeff: You'll get an identity issue. if you get an instance of S1, you
want to be sure that it will related to S2. That they are part
of the same aggregate thing. "Each port provides semantically
equivalent behavior" doesn't mention anything about state or
identity.
[Jonathan writes on the whiteboard:
(1) <service>
<alt>
<p1/>
<p2/>
</alt>
<p3/>
</service>
vs
(2) <service>
<p1/>
<p2/>
</service>
<service>
<p3/>
</service>
see http://www.w3.org/2003/05/wsd-pics/dcp_4974.jpg]
Arthur: the semantic equivalence of ports within a single service is
currently undefined.
[General consensus that neither WSDL 1.1 nor WSDL 1.2 current draft provides any semantics for the relationship between different ports within a service.]
[Lots of discussion; scribe was a participant and hence missed documenting much of it. Not clear its going anywhere .. lots of circular discussions; as usual ;-).]
Taking a straw poll on whether <service> is a single portType / service or not
10 for single portType / service; 2 for keeping it as is
Jeff voted yes, but he would like to have us solve the wider problems associated with the overall space at the end.
[sgg: sgg has similar point of view as Jeff]
and others agreed with that view too (in particular William/HP)
After lunch we will try to frame the problem we want to try to solve and then hopefully people will make proposals on what should be done.
ACTION: editors to reflect decision to have one interface per <service>
--------------------------------------------------------
12:30 Lunch
14:00 Proposal for restricting a service to a single interface (cont.)
Recap from this am: within a <service> multiple endpts refer to the "same" interface".
Arthur: Leave it as "semantically equivalent" and punt to the "web defs".
William: How about 'externally visible'?
Arthur: Whatever the web def of resource is: ws has a single resource
associated with it and endpt refers to a resource. WS add a
set of ops to a "resource" - i.e. describing the interface.
i.e. alternate ways of accessing the "same" resource. When you
make the "same" op call on the same resource, even via
different endpts you get the same result.
Glen: For whatever definition you have of resource, it is the "same"
one for your definition. Orthogonol from issues wrt identity,
semantics. Wants to allow a variety of ways to implement
state/identity mgmt
Arthur: A Web service is associated with a single resource and describes
a set of operations you can perform on that resource, and
those operations can be invoked through >= 1 protocols through
bindings.
[A svc must have exactly one resource, but a resource can have multiple wsdl services (or none).]
Arthur: Groups a set of operations into one interface which is associated
with a resource.
[Question: under Arthur's definition, can I have multiple svc's associated
with a resource? If so how do I indicate which one I want to use?
[An endpt has a single URI which is used to get in touch with an interface.]
[Arthur draws diagram -
"conceptual resource" has multiple interfaces.
Interface has a set of bindings, the bindings are grouped into a "service".
Each binding has the "same" interface,
Each endpt has a single URI. A single URI may be associated with multiple
endpts. see http://www.w3.org/2003/05/wsd-pics/dcp_4975.jpg.]
[Long discussion about resource, identity, services, uri's]
Steve: Talks about the way they have done this in the Grid work - this
approach would generalize and be usable. With the current state:
there is no relationship between services.
[Recap: Resource offers one or more interfaces where an interface consists of a collection of ops. Each interface may be accessed by one or more endpts, where and endpt represents a binding of that interace to a particular protocol. Each endpt has an URI. Note: there can be multiple endpts using the same binding. Interfaces offerred by a resource MAY be related to each other, but so far this group is not defining what those relationships might be. A corollary: one URI may be associated with multiple endpts - typically this will not be the case--except of course for .net:-). A "service" is a collection of endpts bound to the same interface and therefore the same resource.
[plh-fr: <service interface='qname'>(list of endpoints...)</service>]
What is the name of the attribute used for interface? [Consensus on "interface"].
ACTION: Editors to update the spec with these decisions
--------------------------------------------------------
14:30 Multiple endpoints with the same interface [5]
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0052.html
Next issue: do we want the grouping aspect of services a/o interfaces?
[jeffsch: The value of binding/@interface for every service/endpoint must be the same as the service/@interface?]
Sanjiva draws another service attached to our canonical resource.
It was noted that the 2 services are related to each other by virtue of being associated with the same resource.
[jeffsch: Short discussion on whether binding/@interface could be a specialization of service/@interface; decided to postpone until we review bindings because may eliminate @interface on binding.]
Discussion of how to indicate this grouping. Group the services directly, indirectly possibly via uri's. Discussion of whether we should even go there for now. Multiple arguments for delving into the topic - otherwise everyone will invent their own way to do so this.
Sanjiva: not sure that we can solve the problem completely enough.
Glen: We can only go as far as the ambiguity inherent in the term "same resource"
Jonathan: noted the only objection was a (semi?) raised eyebrow - so we're off.
sanjiva options:
1. indicate association between any 2 services - unlimited scope for associations
or
indicated association between services = limited scope to the same resource
<service>
<association type="URI">xs:QName</association>
</service>
2. service group defintion
<serviceGroup>
<service>
</service>
</serviceGroup>
or
<serviceGroup service="list of xs:QNames"/>
3. indicate the association by using the resource's uri
<service resource="uri of underlying resource"/>
Discussion over syntax, what level to introduce the concept? Svc groups refer to services that are already defined at the top level.
<servicegroup service="list of qnames"></servicegroup> - possible proposal
Umit: Without adding some semantics to a svc group, beyond the syntax,
seems rather useless.
Use is that a software component can publish how it can be managed. Definition of static grouping, which is what is being proposed, is useful.
jeffsch: describes how rdf could be used in the same way
--------------------------------------------------------
17:00 Break
17:15 Multiple endpoints with the same interface (cont.)
Do we need generic associations? Simple syntax for experssing same kind of association only one level up (for services) ?
Connection to tools, e.g. stub generator
Sanjiva: SG becomes a "service group" desc language, not just service. A
tool generator could generate get me other refs. In favor of
assoc approach.
Steve: Could be a way to solve problems we were describing.
[What about the uri approach?]
william: People care about many different levels in the wsdl, not
necessarily the "final" thing - i.e. service or svc group.
Sanjiva: Arguing against service group syntax which makes it look like
svg group is "highest" level.
William: How do i find the other services? otherwise all are equiv.
[#3: implies add a property with service's uri. If i have 2 wsdl files with 2 different svc, where do i describe the svc group?]
Sanjiva: 3 is most accurate as reflecting the picture we had on the
board before
Glen: Claims 1 and 2 also say that - but semantics not captured by
syntax.
[Everyone else seems to disagree.]
Glen: Even though the uri is not specified in the srv group, the
constraint nevertheless MUST ?? be enforced
Umit: Argues that one should be able to get to the svc from uri
[GlenD: The URL is implicit in <serviceGroup> just EXACTLY as it is in
<service>. The constraint is non-enforceable in either case.
The semantics of <service> says "by specifying this, this
says these endpoints are all the same resource". The semantics
of <serviceGroup> would say precisely the same thing. (about
services).
[jeffsch: The URL for the common _resource_ is implicit in ServiceGroup?]
[GlenD: Jeff: yes, just as it is in <service>.]
[Option 3 would allow one to use some other mechanism (RDF?) to assert that two different uri's are point to the same resource.]
Arthur: #2 is the "smallest" thing we can do.
[Discussion as to which is more "complete" - can find all the other svcs.]
william: #3 is elegant solution that meets mgmt reqs.
steve: Wants to say wrt interface def, mydiscdriver requires a
discdriver mgt interface?
[General consensus is that requirement is different - there are other ways to address the problem.]
sanjiva: All the proposals need additional syntax at the port type level
in order to address steve's req.
william: In #3 would it be required?
[Answer: probably not required.]
[Discussion on how this all might work wrt develop tools/runtime.]
Straw poll:
1: 3
2: 0
3: 5
donothing (external): 4
Straw poll between winners:
3: 8
donothing: 4
Jeffm: #3 allows us to provide a mechanism to check for svc equality.
Sanjiva: Likes 3 more now, because it doesn't preclude external/RDF
approach
Jonathan: 3 is fairly straightforward, except for deciding if resource
attribute is optional.
william: Wants to think about whether it should be required
[Everyone jumps on william.]
Sanjiva: 3 doesn't express the requirement of how to express that a
svc "needs" a mgmt interface.
RESOLUTION: adopt #3 with attribute being optional.
ACTION: Editors to update draft to reflect resolution.
--------------------------------------------------------
18:00 Describing endpoint references [6].
R085 and XML Base [7]. Dynamic discovery of a service [8].
[6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/att-0088/R085-2003-04-22.html
[7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0142.html
[8] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0004.html
Postponed until tomorrow morning.
18:00 Adjourn
--------------------------------------------------------
Raw IRC log: http://www.w3.org/2003/05/12-ws-desc-irc
Received on Monday, 12 May 2003 13:26:16 UTC