- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 15 May 2003 03:05:45 -0700
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
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