-------------------------------------------------------- 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-ircReceived on Thursday, 15 May 2003 06:05:55 GMT
This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:14:35 GMT