Minutes, 13 May 2003 WS Description FTF

--------------------------------------------------------
Tuesday 13 May
--------------------------------------------------------

Present:
 Glen Daniels           Macromedia
 Youenn Fablet          Canon
 Steve Graham           Global Grid Forum
 Philippe Le Hegaret    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

Observers:
 David Orchard          BEA (Partial - phone)
 Bejan Parsia           U of Maryland, Semantic Web

scribe: William Vambenepe
--------------------------------------------------------
09:30 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


Arthur gives a presentation: "describing messages that refer to other web services".  See 
http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0043/R085.ppt (Powerpoint), http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0043/R085.pdf (PDF).

Arthur:   Entry level construct proposed: URIs.  But it should not 
          preclude higher-level constructs from being used (like 
          WS-Addressing).
Steve:    How about sending references to not just services but to 
          other specific WSDL elements, like an operation in a port.
Arthur:   Roger Costello's article: http://www.xfront.com/REST-Web-Services.html

[Example of new proposed element placed in interface/operation/output:
  <wsdl:endpoint name="partURI" 
                 part="return"
                 xpath="/p:Parts/Part/@xlink:href"
                 interface="tns:partInterface">
(or input presumably)]
JJM:      (Maybe not in the input?)
sgg:      Why not in the input? This could be used as input to a 
          subscribe operation (in a notification use case).
[and in binding:
  <wsdl:endpoint name="partURI" binding="tns:partHTTPBinding"/>]

Arthur:   Located in binding/operation/output (or input).  Could allow 
          the wsdl:endpoint/binding attribute above to contain a list.
[now Arthur shows an example using WS-Addressing instead of XLink and anyURI]
Arthur:   Explains how this works for interface inheritance and 
          interface collections.  You have 2 wsdl:endpoint elements, 
          using 2 XPath expressions (in interface/operation/input or output)
          (in the case of interface collection).  Arthur provides a callback 
          example.

--------------------------------------------------------
10:40 Break
11:10 Describing endpoint references (cont).

Arthur restarts his presentation.  Describes the content of the endpoint reference interface description.
Glenn:    argues that the schema is a perfectly valid place to put 
          this annotation.  In the case where you don't know at design 
          time that a given anyURI might point to a web service, then 
          it is appropriate to put the annotation outside of the schema, 
          like in the WSDL. But in the static case, the right place is 
          in the schema.
Sanjiva:  You don't want to specify the binding you are using in the 
          type.
Glenn:    Sometimes you do, sometimes you don't.
Umit:     We need a structure (uri+interface+binding) to be able to 
          reference an endpoint uniquely. Why not define such an 
          "endpoint reference" type to do that?
Arthur:   This would be just for runtime, not design time.
Umit:     No
Arthur:   What you propose is close to WS-Addressing.
DaveO:    We ran into some of these issues when working on XLink. One 
          requirement is to have something like WS-Addressing with 
          built-in type info so you can have strongly-typed references
          WS-Addressing is close to the solution to the requirement we 
          are considering here (R085).
Arthur:   My proposal allows you to use WS-Addressing.  But if you want 
          to have design-type info, then the type info has to be 
          somewhere available at design time, like schema or WSDL.
DaveO:    How about using WS-Addressing in WSDL?
Arthur:   In WS-Addressing all you can do is point to a port and from 
          there find the binding. But the port has to be in a service 
          element and have a URI. But you might not know the URI at 
          design time, so you can't really create this piece of WSDL.
Jeffsch:  Maybe create an extension to WS-Addressing to point at the 
          binding.
Arthur:   Wants a simpler way.  My proposal is consistent with the 
          design of WSDL and maximizes possibilities of re-use at each 
          level.
JeffM:    We all agree we need interface+binding+URI to make an 
          invocation.  What we are discussing is where each piece of 
          this comes from.  Let's decide where we need to standardize 
          how people want to get this info and they can use any other 
          way they want.
Arthur:   R085 is the case where you want to know they typing info 
          (interface and binding) at design time and the URL at 
          runtime.  The case WS-Addressing address is when the client 
          does not know anything at design time.  Or the server.  (If 
          the service receive WS-Addressing info in its input message.)
JeffM:    Sure but then when the service uses this it is acting as a 
          client.
[Glen/JeffM discussion on what constitues strong typing and where you 
have an application-level error versus a misused URI.]
Umit/JeffM: Argue that if what is at the end of a URI that is expected 
          to be a web service is not a web service, then the strong 
          typing doesn't work. Glen argues that this is similar to 
          an application error.
Jeffsch:  There is a separate discussion about how I can send at 
          runtime a message containing a reference. But this is a 
          separate requirement, not the one Arthur is trying to meet 
          today.
Arthur:   Explains why we shouldn't put the annotation in the schema.
          I have a single employee schema (with a URI) and 2 apps 
          that use it, a real estate app and an HR app. I want to 
          defer the use of the URI at runtime. It will be used for 
          different services, real estate or HR.
[Glen: This is equivalent to "Object getDept()" as opposed to "FinanceDept getDept() / RealEstateDept getDept()". There are cases where you want to do that, and other cases where you don't. Both are valid.]
[Jeffsch: Agreed. If you want static typing, you'd derive FinanceDept from Object, n'est-ce pas?]
[Glen: oui.]
[Glen: Just like everything else :)]
[JJM: Très bien.]
Arthur:   Explains why he chose to use Xpath (which is applied to the 
          instance doc) instead of schema component designators
Umit/Glen: Argue that using schema type info is much easier to use 
          than XPath for most cases considered here.
Arthur:   Defends that XPath has a wider applicability.
Jonathan: By using XPath you are implying the data is in the instance.
DaveO:    One of the main reasons xpath would be useful is if the author 
          of the WSDL does not have control of the schema and therefore 
          can't add a schema annotation. but this might be out of the 
          80/20 case.
Glen:     But if you only use schema annotations you can't specify a 
          binding.  The annotation in the schema is really useful if you 
          are willing to define a "marker" type that wraps for example 
          anyURI and say that this is a "departmentREference" for 
          example.
Arthur:   Lists the open questions (and recommendations on answers) on 
          his proposal.
[question discussed: should we allow binding to a derived interface?]
[Jeffsch: Oracle\Jeff said something interesting about how allowing endpoints to implement extended interfaces beyond the interface! Would help with versioning scenarios!]
[Glen:    ...only where versioning is additive, though...]
[jeffm:   ... yes, we were talking about inheritance (more derived interface)]
Jonathan: This proposal represents functionality that we could add to 
          WSDL. Does anyone not agree that we want to add this 
          capability (independently of how we go about it).
[No-one speaks against adding this capability.  Groups seems to agree that we want to standardize this in this group.]
[Jeffsch: Thank you Arthur for the professional proposal and its obvious attention to detail.]
Jonathan: Main point is whether or not the endpoint annotation belongs 
          in WSDL or in schema.
Glen:     We need to identify the spectrum we are trying to solve and 
          acknowledge that there are other needs out of this.  Wonders 
          about the IP on WS-Addressing.
JeffM:    Notes that it is a proprietary spec.
Jeffsch/Glen: Discussion on whether the schema/WSDL difference maps to 
          designtime/runtime
Jeffsch:  WS-Addressing is a use case but we as a group do not specify 
          it. we don't prevent it. In a 1st stage (not worrying about 
          late binding) we don't need to worry about WS-Addressing IPR.
DaveO:    If some of the requirements on WSDL would be easier to solve 
          if WS-Addressing was in scope then it would be logical to 
          approach the authors of WS-Addressing.
Sanjiva:  R85 is design time only.
Jeffsch:  If we disagree on the interpretation of a requirement we 
          should break it in two and consider both. This might be what 
          R131 is. Is something missing there?
DaveO:    R131 is clear as it is.
Jeffsch:  Arthur's proposal only addresses R085, not R131.
Jonathan: Does solving R85 presupposed anything about us solving R131 
          or not?
[silence...]
Sanjiva:  No opposition to asking WS-Addressing authors to submit 
          WS-Addressing but this is not necessary for this.  We can do 
          all the schema-level work without any need for WS-Addressing.
Glen:     As long as you do the binding at design time.
Sanjiva:  This is what this WG is focused on, design-time issues.
[Discussion on whether we need (or it would help) to have WS-Addressing in scope or not.]
Jonathan: Let's get action items out of this discussion.  If we limit 
          this to R85 it would help us solve the pb. We have a proposal 
          and 3 issues: allow derivations, annotation in schema, can 
          not only the endpoint uri but a lso a qname for the binding 
          be used.
Arthur:   Why stop at the binding, why not the interface?
Jonathan: Ok, let's extend the last issue to be not only binding but 
          also interface.
Glen:     We should not restrict to one way of doing this. WS-Addressing 
          is one, BPEL has its own way of doing it, etc...
[DaveO: this reminds me of the xlink element syntax vs attribute (aka runtime mixin) syntax. Sounds like both will be used in the wild.]
Jonathan: Asking for volunteers to write proposals for these 3 issues.
          Clarification of 1st issue: derivation question is in this 
          list because Arthur raised this issue.
Glen:     Is it ok for an endpoint to point to an interface derived 
          from what is expected? This is a separate issue.  2 cases 
          in which this happen is when endpoint in a service element 
          and endpoint reference also gives you expected interface.
[Marsh: RESOLUTION: Record these as new issues.]
Jonathan: We need someone to show how a schema annotation would work.
Philippe: Do we create our own type that extends anyURI?
Glen:     Should be able to both derive a type and use this info or 
          annotate a particular instance of an anyURI.
Jonathan: An annotation calls out that there is something new.
[  <simpleType name="PersonUri">
     <restriction base="xsd:anyUri"/>
   </simpleType>
   <operation name="foo"...>
     <input>
       <endpoint part="return" type="personUri" 
                 interface="tns:PersonIntf"/>
     </input>
   </operation>]
ACTION: Umit to write up the schema annotation proposal.
[Jeffsch: R131: The WG SHOULD define components that may be used within Messages to refer to other WSDL components. (From DO. See also R085 and R120. Last discussed 6 Feb 2003.)]
[Discussion on the lack of location attribute on import.]
Arthur:   Asks DaveO if QName would satisfy R131 if there is a way to 
          locate the WSDL doc. Or is the namespace sufficient.
DaveO:    Namespace should be sufficient.  I don't want to see a 
          solution for R85 that doesn't work for R131 and vice-versa.
Jonathan: Based on our schedule we should decide here whether or not 
          we want to solve R131.
Glen:     We could solve it in a separate note.  WSDL group is about 
          WSDL, this would not be in the WSDL doc.
JeffM:    Note is not normative.
Glen:     Ok, then I guess it would be a new part.
Jeffsch:  The question is does anyone volunteer to do that.
Jonathan: Poll on how many people think we should solve R131 (by 
          amending the proposal for R85 to solve R131).
sanjiva/arthur: r85 and R131 are not that similar.
Jonathan: We separate both and for now we focus on R85, not 
          worrying about R131.
Arthur:   R131 is too abstract, do you have more specific examples/use 
          cases to get me energized about it.
ACTION:   DaveO to send a motivating example for R131.
JJM/Jonathan: Clarification/discussion on new issues we created as 
          they relate to the WSDL issue list.  Some issues listed 
          above are issues on Arthur's proposal, not issues on the 
          WSDL spec.

--------------------------------------------------------
13:00 Lunch

scribe: Youenn Fablet
--------------------------------------------------------
14:30 OGSI ServiceData - Steve Graham

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0045/Modeling_State_in_WSDL.ppt

[Glen:    We've changed the agenda to account for people leaving and 
          item priorities.  Want to discuss the <message> construct, 
          but we're waiting for Oracle to return.  Covering service 
          data now.  (Steve Graham)]
[Steve presenting "Modeling Elements of WS State in WSDL".]
Glen:     What about name clashing between get...set.. state ops and 
          ops.
Steve:    No pb because we already cleaned name clashing ops in WSDL.
          Commited to sync with WSDL1.2 at some time.
William:  The base portType defines get,set ops and derived 
          porttypes define state values.
Steve:    Yes.
Arthur:   In case of notif, where does the notification get sent?
Steve:    It depends on the subscribe(expression) input.
Jeffsch:  What about querying a defined but non existent value ?
Steve:    You get an error. All services that implement a pt with 
          defined state values in it must implement these values.
Jonathan: It seems like this is a lot of specific mechanisms for 
          a dedicated thing.
Jeffsch:  A very dedicated set of conventions.
[Discussion about : is this functionnality core?]
Arthur:   Webdav is an http implementation which is a precedent of 
          that mechanism with its own http verbs.
[Arthur: The WebDAV standard defines properties for resources. See http://www.ietf.org/rfc/rfc2518.txt]
[Arthur: There is a related search spec for WebDAV: DASL, see http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html]
[Jeffsch: http://www.webdav.org/]
?:        Javabeans has this concept of properties.
Steve:    Some organisations would like this functionality and 
          might make a different mechanism => interop pb.
Philippe: The grid cannot submit something to W3C because they are 
          not a W3C member.
Glen:     Advocate for simplicity.  Advocate to use extensibility 
          mechanism, as the xmlp wg did.
Umit:     You can separate security but this kind of mechanism is 
          always part of the component model.
Sanjiva:  The simplicity argument does not stand in the WS world.
          If this mech is in the WSDL ns, everybody must implement it.
[Profile system ?]
[Discussion about : is this mech core, module... ?]
Arthur:   Very similar to webdav.
Glen:     Interesting to bind this mech to webdav if supported, 
          another protocol otherwise.
Arthur:   Favour this proposal if it was aligned with webdav.
Steve:    Interesting to make a tf to push this proposal in the 
          more general ws space.  Then ogsi would adopt this broader 
          ws mech.
William:  What about the ogsi IP terms ? I would like a tf to 
          investigate this.
[Discussion about the goals of the tf.]
[pb of resource to include this in WSDL on time]
[Discussion about interest of vendors to that feature]
[Extensibility versus interoperability]
[Interest in the tf ?  william, umit = yes]
Jonathan: tf coming with a proposal ?
Arthur:   What about communicating with the webdav community ?
Steve:    Webdav is not about WSDL. Searching for visibility in the WS 
          space.
Glen:     What about another group not managed by WSDL wg and come up 
          with a proposal in time for toronto f2f ?
Phillipe: Why not a tf then ?
[Strawpoll: six versus one to include this idea in WSDL version 1.2
RESOLUTION: Create a tf for this subject: Steve is the chair, william 
          is interested, Umit if her management agrees.


--------------------------------------------------------------------
15:15 Break
--------------------------------------------------------------------
2.  Removing message.  Umit's posting on the value of part as an
    abstract concept of WSDL [.1].  Sanjiva asks for more rationale
    as to why his proposal did not fly [.2], and suggests that
    inheritance and overloading go together [.3].  Roberto's original
    proposal at [.4].  Direction suggested by Dale [.5]

    Postponed until we have a little better idea of what our bindings
    will look like.  Gudge's responses [.6, .7] to Umit's examples [.8]

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0011.html 
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0020.html 
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0014.html 
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0035.html 
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0040.html 
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0006.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0013.html 
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0005.html 


[By popular demand, and productive lunchtime conversation, topic of removing wsdl:message or not was entertained.  Sanjiva put together a short presentation.  See http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0046/Simplifying_Bindings.ppt]

[Jeffsch: FYI, here's the XML Schema for the SOAP 1.2 Envelope: http://www.w3.org/2003/05/soap-envelope/]

Jeffsch:  Soap:body accepts attributes according soap spec and soap 
          schema (soap v 1.2)
Umit:     Mapping from schema to parts (programming model) is very 
          difficult (see mailing list)
[Umit:    http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0005.html 
          is the reference for difficulty in mapping arbitrary complex 
          types to logical parts]
Jeffsch:  Back to umit's concern.  One issue : how much of schema 
          should we allow within wsdl:operation ?  We should have 
          rules to build WSDL if building from a programming model.
          Another community is only interested in what is on the 
          wire (no programming model needed).
[Discussion about programming model from WSDL.]
Umit:     If xsd:sequence only, programming model can be retrieved 
          but it is not possible if we make no restriction.
Sanjiva:  With a foo(a,b,c) in three languages, three different 
          generated from code WSDLs.
Jeffsch:  A lot of things needed for a programming model are not 
          present today.  We should add indication for a 
          programming model in the WSDL but not by restricting 
          messages on the wire.  If restricting messages, the 
          prog model community will be happy but not the msgs 
          community.
Jonathan: Jeffsch= passing a programming model from one node to another
          Umit= building a programming model from a message on the wire
Glen:     There is a need to have in WSDL a flag to switch between 
          rpc/doc SOAP messages.
Sanjiva:  We should determine the subset of xmlschema that goes 
          in the schema of the operation messages.
JeffM:    What about overloading ops ?
Jeffsch:  There was a discussion about this a year ago with people 
          from both overloading and non-overloading community
          we finally decided with a call.
[Discussion about relationship between programming model, messages and WSDL.]
Glen:     If we create another RPC system, the SOAP1.2 RPC system might 
          be unused.
Jeffsch:  We could do a far better job than WSDL1.1 to round trip the 
          programming model.
ACTION:   Jeffsch, Sanjiva, Glen, Umit, JJM to come up with a proposal 
          to get rid with the message construct, add programming hints.


--------------------------------------------------------------------
17:00 Adjourn
      Group dinner in Saint-Malo [23].

 [23] http://lists.w3.org/Archives/Member/w3c-ws-desc/2003May/0004.html

-------------------------------------------------------
Raw IRC log: http://www.w3.org/2003/05/13-ws-desc-irc

Received on Thursday, 15 May 2003 06:05:55 UTC