W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2003

Minutes, 12 May 2003 WS Decscription FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 12 May 2003 10:26:10 -0700
Message-ID: <1113DDB24D4A2841951BFDF86665EE1906288819@RED-MSG-10.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Monday 12 May

 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 />*

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 

[Jonathan writes on the whiteboard:
(1) <service>


(2) <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 
[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
   indicated association between services = limited scope to the same resource
     <association type="URI">xs:QName</association>
2. service group defintion
   <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 
[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 
[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 
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:29 UTC