- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 15 Nov 2002 10:01:45 -0800
- To: <www-ws-desc@w3.org>
---------------------------------------------------------------------
Monday 11 November
---------------------------------------------------------------------
09:00 Introductions and logistics
Logistics, including dial-in numbers [1].
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
Steve Lind AT&T
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Don Mullen Tibco
Arthur Ryman IBM
Adi Sakala IONA Technologies
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Don Wright Lexmark
Sanjiva Weerawarana IBM (till 16:00)
Joyce Yang Oracle
Phone:
Amelia Lewis TIBCO
Observers:
Martin Chapman Oracle
Francisco Curbera IBM
(phone) David Orchard BEA
[1] http://www.w3.org/2002/ws/desc/2/04/f2fNovLogistics.html
---------------------------------------------------------------------
Assignment of scribes:
Mon AM: Don Wright
Mon PM: Kevin Liu
Tue AM: Arthur Ryman
Tue PM: Jacek Kopecky
Wed AM: Tom Jordahl
Wed PM: Philippe Le Hegaret
Scribe: Don Wright
---------------------------------------------------------------------
09:20 Spec update (editors):
Requirements [2] - in last call
Marsh: Requirements document in last call until Dec 31.
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/requirements/ws-desc-reqs.html
---------------------------------------------------------------------
Usage Scenarios
Marsh: Usage Scenarios no update
---------------------------------------------------------------------
Primer [3] - when do we publish?
Dbooth: Primer - Not much change since the last face to face except adding Philippe as an editor. Could still use some examples if people have some to contribute
Philippe: Public draft in January
[plh-home: we can reevaluate the publication of requirements at the next f2f meeting.]
issue-transition-documentation [4,5]: Do we need to provide user
documentation describing the transition between WSDL 1.1
and WSDL 1.2?
Marsh: Should we put something in the primer about how to move from WSDL 1.1 to 1.2?
dbooth: Perhaps publish as a note
tomj: Should be in the document as an appendix or some other way versus being in a separate document
marsh: suggest we have this as a non-normative part of the spec
alewis: suggesting that we wait until more things settle down
sanjiva: The current editors should create a table of contents as an outline of what's different between 1.1 and 1.2
ACTION: Editors to add an appendix outlining the areas requiring transitional documentation. Specific text TBD.
[3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-primer.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0247.html
[5] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-transition-documentation
---------------------------------------------------------------------
Part 1 [6] - when do we publish again?
Part 2 [7] - when do we publish again?
Marsh: When do we publish again?
[plh: December Moratorium
End of year, US/EU Holidays
23 December 2002 - 3 January 2003 [7a]]
Marsh: Due to W3C blackout periods, publishing in mid-December is about right
Gudge: We will shoot for Dec 13th. We will have it stable by Dec 6th and vote on Dec 19th
Marsh: We have all the part 1 issues on the agenda for this face to face and can then focus more on part 2
[6] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html
[7] http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12-bindings.html
[7a] http://lists.w3.org/Archives/Member/chairs/2002JulSep/0096.html
---------------------------------------------------------------------
RDF mapping
Marsh: no update
Marsh: we will work with the RDF interest group to actually get this done
---------------------------------------------------------------------
Issues list [8]
Marsh: a separate document with all the issues and resolutions will be needed for last call
Philippe: The Director will go through the issues list in detail. Example: [8a]
[8] http://www.w3.org/2002/ws/desc/2/06/issues.html
[8a] http://www.w3.org/2002/07/DOM-Level-3-Events-issues/all.html
---------------------------------------------------------------------
Revised Schedule
Marsh: Feeling optimistic about part 1. Not so with part 2. The earliest we call do last call is probably the March meeting. Normally need at least 2 months of last call. Optimistically, Sept 2003. Are people going to start implementing before the spec in CR?
GlenD: Not until it is stable. Do not need language bindings in order to be able to make statements about interoperability; can base testing on wire-formats
Marsh: Should we push for next fall or "wait until it is right"??
GlenD: WDSL 1.1. is getting people by for now. Doing it right and being done with it is better than having to do WSDL 1.3.
SteveG: We may have to do a 1.3 because we didn't have enough experience with it
Sanjiva: There's a difference between planning to do a 1.3 and discovering we need to later. There were issues closed that were to be considered again for 2.0. Now we are reconsidering many of these for 1.2
Marsh: we've already moved far beyond just fixing errata, etc.
Sanjiva: we can't go back to just simple fixes
Marsh: what do other people think about driving for a schedule versus right and complete?
Jacekk: Maybe a straw poll?
Tomj: people are jumping on the 1.1. train. Many may think there are too many changes and will stay with wsdl 1.1
roberto: the changes were are making are things that have been brought up by real world implementors
Jacekk: we should do it right
TomJ: We can't be "too" late
Gudge: There are big holes in 1.1... there are things that can't be done with 1.1 that we're are adding
<<interactive discussion about missing features, what the marketing is using, if implementors will wait>>
GlenD: Should we have a core spec that comes out early and then extensions later
Marsh: There seems to be almost no one with hard product schedules that will be impacted by pushing out the date. Best guess for going to REC is fall 2003.
---------------------------------------------------------------------
10:00 Name uniqueness issues
- issue-toplevel-element-name-uniqueness [9]
Marsh: Do we require all the top level element names to be unique
Dbooth: Doesn't solve the problem but makes things better
Gudge: Makes things worse. Imports with same namespace causes problems
Dbooth: If you are working in the same namespace, you are coordinating the namespace
Philippe: we are encouraging people to use the same vocabulary across the web. It would be simpler if we agree on top levels than if we don't
Dbooth: WSDL 1.2 is intended to be used by higher level things, such as choreography.
Philippe: all the tool kits are generating it already
Marsh: Are there other points or issues we need to discuss or have we all already made up our minds?
Dbooth: It is a judgement call
Arthur: It doesn't solve the R120 problem
<fast moving "religious" discussion>
Roberto: prefers strongly typed
Joyce: difference between top down versus bottoms up approaches can impact tool makers
[jeffsch: top-down would be simpler with uniqueness across all top-level names
... bottom-up would be simpler with separate symbol spaces
... tools would have to do unnatural things when mapping from code to wsdl if there is ==1 symbol space]
Jacekk: The RDF problem Art describes is easily solved by several means
Dbooth: several tool kits can easily do these things if things are descibed in generic formats
"russian doll" and "code first" are two scenarios that do not support single symbol spaces
JacekK: yes, these two scenarios support multiple symbol spaces
<< more religious discussions >>
Sanjiva: we are focused on making it easier for the user versus the implementor
Marsh: there are lots of good reasons on both sides
Arthur: should it be easier to author or easier to use.... should be easier to use because it is processed many times
Marsh: who would like to make our top level names unique?
Straw poll: a few for, many against
DECISION: we will not make top level names unique
[9] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-toplevel-element-
name-uniqueness
---------------------------------------------------------------------
10:30 Break
10:50 R120 URI-Reference revised proposal [12] (Arthur)
Arthur steps through his presentation (Powerpoint [12a], html [12b])
Roberto: Would the URN scheme need to change from version 1.1 and version 1.2 of WSDL?
Jeffsch: "http" didn't change from v1 to v1.1
???: The version is contain in the messages
Jacekk: thinks the wsdl:urn: should be removed from the proposal because it is unnecessary
DaveO: suggests sending this situation to the TAG
Jacekk: deficiencies in RDF should to taken to the TAG
Marsh: Proposes to sent Arthur's proposal including URN to the TAG
Daveo: telling tag "here's some problems we are having, please solve them" would not get the best reception
...: rather, saying here's a solution and is where we are leaning
JeffM: There seems to be similar issues open in the e-mail list
...: one of them is issue 28
ACTION: David O will post a summary of these TAG issues
Roberto: Imports would not be compatible with using the Xpointer....
<Art continues by presenting alternative solutions>
Art: Last alternative is XPointer Framework which is consistant with R120 proposal
Dbooth: RDF would prefer a consistant solution over a simple one
Marsh: Propose lunch and then spend 20 minutes to chose an acceptable one
Sanjiva: (To dbooth) Why does RDF prefer consistant over simple?
Dbooth: Is a URI and opaque string or not?
... some say yes, others no
... there are some benefits to not using it as an opaque string
[alewis: A namespace is an opaque string; a real URI is not. It is always decipherable, given support for its scheme, by starting at the scheme part and parsing.]
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0038.html
[12a] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/att-0047/01-R120.zip
[12b] http://www.w3.org/2002/ws/2/11/R120_clean.htm
---------------------------------------------------------------------
12:00 Lunch
13:00 R120 URI-Reference revised proposal (continued)
Scribe: Kevin
Marsh: follow the tag and ask for advise which solution to choose
Marsh: take Arthur's proposal including the urn part as our working draft
Jacek: how about if the TAG get back something different
Arthur and Phillipe discuss the urn scheme
Marsh: how about the TAG asking why not URN
DaveO: don't like the URN solution, but also realize problems with other solutions
Marsh: Let's take a straw poll
DaveO: suggest writing a solution in the WD, then asking TAG for approval/disapproval/thoughts given the solution's architectural significance.
DBooth: problem with Media type is not specific to WSDL, it's generic. Propose using targetNamespace + Fragment Identifier
paco: like document URI proposal
-- equivelance can be determined by targetnamespace + local name
DaveO: make sure any proposal like this should have strong documentation
Arthur: to make progress, can we at least eliminate some of the alternative proposals
DaveO: DaveO: this is really good stuff that should be fed into the TAG as it's doing it's work.
Jeffsch: Tell TAG that there is a way to do this - Arthur has proposed quite a few different ways to do it
Dbooth: +1 to jeffsch's suggestion
Sanjiva: WG pick one of the proposals and put it in the spec as a non-normative part
Jacek: must be normative
<< some discussion on what it means for this to be normative. Agreement that it cannot be normative. >>
Arthur: we can rule out some alternatives
Marsh: it may end up with RDF mapping or other documents
Straw poll:
Option 1. TargetNamespace + urn:wsdl prefix (3 votes)
Option 2. targetnamespace (9 votes)
Option 3. URL of wsdl document (4 votes)
(9 abstentions)
Marsh: see more people with Option 2, let's move on with option 2
DaveO: volunteers to help on wording
Arthur enumerates 5 options for fragement syntax
1. id attributes on all WSDL conceptual elements
2. require all NCNames be unique
3. Use full blown XPointer
4. Use XML Schema Nuns proposal ( modified version )
5. Use XPointer framework approach
Agreement to eliminate option 1.
Gudge and sanjiva pointed out that 2 was eliminated before the break
Agreement to eliminate option 3.
Straw poll:
Option 1: XML Schema Nuns (9 votes)
Option 2: XPointer framework approach (8 votes)
(9 abstentions)
No consensus. Continued discussion on pros and cons of different options, and their interactions with the previous poll, see arthur presentation above
Marsh: let's recast the options as follows:
Option 1: location#schemaNun (3 votes)
Option 2: targetNamespace#ArthurNun (~10 votes)
ACTION: Arthur will modify proposal as discussed and send to editors to be included in part 1 as non-normative appendix, including a note regarding non backward compatibility wsdl 1.1 (this proposal doesn't support overloaded operations).
---------------------------------------------------------------------
issue-operation-name-uniqueness [10]
Gudge has checked in to CVS a proposal for promoting operation as a top level construct [10a]. We'll postpone this issue until tomorrow when we discuss that.
[10] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-operation-name-uniqueness
[10a] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.toplevelops.xml
---------------------------------------------------------------------
issue-fault-name-uniqueness [11]
Postponed.
[11] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-fault-name-uniqueness
---------------------------------------------------------------------
Output operations (issue-remove-solicit-response-operations [13],
issue-remove-notification-operations [14])
- Pub/Sub (Joyce, Sanjiva, ...)
- Example TCP binding for SOAP (Jeffrey, Don Mullen)
Sanjiva summarize where we are: some argued that solicit response is used for pub/sub. He took an action item to make a proposal for make pub/sub top level. Proposal can be found in mail list [14a]. Amy's critique at [14b].
Alewis: That's all synchronous stuff ... still not pub/sub.
DaveO: my company will be disappointed if output operation is removed
KevinL: solicit response is useful in exchange scenario- used to describe consumer requirements
SteveL: support DaveO
More discussions on creating first class event constructs. A few argued for that we should keep wsdl in the scope of describing a services node, not orchastration.
DonM: TIBCO needs output operation
Alewis: The service address is the publication address.
DaveO: alewis, that's the service address where the subscriber wants the publisher to publish to?
alewis: DaveO, No, the address that the publisher wants to publish to.
[13] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-remove-solicit-response-operations
[14] http://www.w3.org/2002/ws/desc/2/06/issues.html#xissue-remove-notification-operations
[14a] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0157.html
[14b] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0029.html
---------------------------------------------------------------------
15:00 Break
15:20 Output operations (continued)
Amy Lewis summarize TIBCO's use of sub structure
Jeffsch summarize the IRC case [14c]
Jacekk: don't this issues should belong to wsdl binding
Gudge: this is just one situation that we think output operation can be used. Not necessarily true that output operation should be handled by orchestration
[alewis: As a matter of fact, using IP multicast there's no "subscription" either, it's just that there are many listeners.]
Tomj: where the discussion is going?
Roberto: complexity added to binding is big
[alewis: The email binding provides another use case. I can produce bindings for netnews, JMS, rv ....]
[tomj: I want to see the WSDL 1.2 spec define the parts needed to make output and output/input operations work in an ineroperable way. Otherwise, we should remove them from the spec]
[DonM: Have you read Amy's email binding [14d]-- internet standards used just in that way -- with specifics.]
Amy, can you post the url for email binding if any?
More discussions, active pariticipation form Jeffery, Glen, Paco, Jacekk etc...
Joyce: wonder how the use cases mentioned use output operation and bindings
DonM: we have a priprietory binding internal
DonM: take soap features extensibility and define an email binding
[alewis: It sounds to me like people want us to show how to use WSDL for output, so that we can demonstrate why we need to improve the specification of WSDL to use it for output.]
Agreed that output operation is not well defined in wsdl 1.1. These are just examples of defining it, it's the job of WG to definie a standard way
Marsh summarizes the current discussion per DaveO request: questions we are facing now is
whether to remove output operation.
[Roberto: my proposal is to allow only one-way and request-response operations in portTypes and let a service declare that in requires or provides a portType; all current uses of output-first operations would be easy to model and the only drawback is that you'd end up adding an extra portType]
[alewis: Roberto: Unfortunately, this does not permit multicast to be modeled in WSDL.]
[JacekK: amy, that's a good point]
[Roberto: amy: why not?]
[alewis: Roberto: Because the model that you propose requires each recipient to expose a separate address. Multicast typically uses a "logical multicast address" which reduces traffic, as the protocol takes care of details of delivery.]
[Roberto: amy: not necessarily. a portType provided by a server can do multicast -- it's up to the binding to define that]
[JacekK: but that's more like an intermediary]
[alewis: Roberto: I don't understand how that would work, or how it could possibly provide a simpler, less complex model than simply modelling existing multicast.]
[GlenD: Just tuned in to this discussion - couldn't you just say that the "logical multicast address" has to implement the required port type, just like any other kind of reply-to address?]
[JacekK: but that's more like an intermediary]
[GlenD: howso?]
[alewis: GlenD: it is, in fact, possible to create two WSDLs to define one service. But I don't see why this is preferred, and it raises interesting questions about how to determine which one to use.]
[GlenD: I'm not sure it's always preferred, but I can certainly see cases where it's nice to indicate "callback interfaces" as a whole, as you might do in a language like Java, rather than having to infer the "virtual port type" out of the output operations exposed by a service...]
[Roberto: amy: why two WSDLs? it would be one WSDL, with two portTypes and one service that requires one and provides the other. if anything, I'd like to avoid the case of having a "client WSDL" and a "server WSDL", which is what happens today with this view of "conjugate portTypes" (that is, portTypes with the same operations but specular input/output messages)]
[GlenD: In particular, it might be nice for orchestration languages and such.]
[GlenD: +1 to Roberto, also. Good point.]
[sgg: FWIW, the Grid Services spec does not use output ops for pub-sub]
[alewis: GlenD: I don't have much patience with a pure RPC model; messaging typically has "methods" for which there may be zero, one, or more than one response. IDL can't model this. We could ensure that WSDL is as limited as IDL. But I don't see *why*.]
[alewis: Roberto: I don't believe that I understand your proposal. Could you write it up?]
[alewis: Gudge: in classic pub/sub, every subscriber is a publisher as well.]
[Joyce: Here is my pub/sub proposal using outbound operations. [14e]]
gudge: concerned about being forced to define related operations in separate files
[alewis: Almost zero WSDL 1.1 documents use output operations. Because they *can't*. Because it isn't *specified*.]
DaveO: needs to identify what needs to be defined in order to interop better
[DaveO: alewis, we agree. We think this is a chicken and egg problem.]
[Joyce: In my pub/sub proposal, pub/sub is seperated into parts -- "pub" piece is modelled by outbound operations and "sub" is modelled by wsdl inbound operations. ]
Paco: we do need the output operation functionality, needs to figure out what's the appropriate way to do it
Jeffsch: Heard people saying http is the only interoperable binding in the future. Doesn't agree, My company is planning introducing more interoperable bindings
[alewis: jeffsch: Bravo! TIBCO wants much the same; HTTP isn't as important to us. We just want enough left in to be able to do the extensions.]
[sgg: +1 Jeff]
Jacekk: agree with Jeff that HTTP will not be the only interoperable binding, but it is currently
[GlenD: However, I still think there is a difference between WSDL's SOAP binding and the underlying protocol bindings underneath that.]
[DaveO: +1 to Jeff, except we think that WSDL group, or some other w3c group, should do the additional bindings.]
[GlenD: WSDL, IMHO, should have *one* SOAP binding, and then everything under that in terms of underlying protocols/transports should be handled by the SOAP binding framework and our SOAP binding.]
Dbooth: it's important to support other ways to use wsdl no matter which way to go
Tomj: Agree that HTTP is not the only interoperable binding. There are companies using wsdl1.1 output operations, but they can not talk to each other. This WG should make it interoperable.
[alewis: "Interoperable" is the word that marketing learned when web services happened.]
DonM: we want the feature, but it's still a question if the WG can make it within our timeframe
Roberto: the other proposal of only using input operation, would it be sufficient?
Gudge: if two companies use two different bindings, they are not interoperable anyway
[alewis: "two countries separated by a common language"]
[Roberto: "and joined by an ocean"]
Jeffm: there is a common binding is not sufficient, needs to require other people support this binding
Paco: it will not work if we don't provide a (missing the points). If we don't provide the right way to do it. Wsdl1.1 introduce a brand new concept of output operation without a good specification.
Jeffsch: it's a network protocl idea, not new at all
[alewis: TIBCO's been running a business on this idea for more than fifteen years ....]
[jeffsch: I don't find the split portType idea to be clean]
[GlenD: interface Callback { void doThatThing(String getOnUp); int getStatus(); }
interface Service { void registerInterest(Callback me); }]
[sgg: interesting, the getStatus was more on the Service side in the GGF model]
[alewis: GlenD: No. That *doesn't* work with multicast. It *requires* subscription. It *doesn't* *scale*. The big lesson of the TIB is that pushing subscription up to the application level can't scale to NASDAQ.]
[GlenD: Amy: multicast is totally orthogonal to this]
[GlenD: (I think)]
[Roberto: then declare MyService provides Service requires Callback]
[alewis: GlenD: As a matter of fact, it isn't. There is no good way to describe multicast as request/response.]
[GlenD: I don't see why it's connected. As long as Service does callback.doThatThing("JB") it doesn't matter whether callback is an individual thing or a multicast group or....]
[alewis: The optionality of return (return void||something doThatThing() isn't comprehensible). It doesn't know what the return value is! There is a difference between message that returns null, and a method that returns void.]
Dbooth: would it resolve the issues if output operation is removed, but we provide some other mechanism to provide the same functionality?
[GlenD: um... doThatThing returns void in this example]
Jeffsch: depends on what're the other ways
[alewis: GlenD: That's output-only. It doesn't handle output-input.]
[GlenD: output-input is tricky for multicast in general, I think]
[alewis: Output-input is easy for multicast. It's hard when you don't want to use multicast.]
[GlenD: the rules for collecting the responses are app-dependent...]
Jeffsch: want to be able to describe in same wsdl or different wsdls, don't want to be forced to do one way or the other
[sgg: what code would be generated by an output operation? Ie if I was building a WSDL "interpreter" like WSDL2Java in Axis. I know what input and input/output generate. Wat does output generate?]
[Joyce: Agreed with Jeffrey. Service-to-service relationship doesn't belong to wsdl.]
[tomj: sgg: in Axis WSDL2Java, it generates an error!]
[sgg: tom: yep, understood, but conceptually, what is it even conceivable to generate?]
[Roberto: I believe our implementation ignores output-first operations]
[tomj: BEA implements it in their product. It registers a listener of some sort.]
Marsh: how to proceed? there seems to be small number of people in both camp can not live with the other way. Continue discussion tomorrow.
[14c] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0044.html
[14d] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0126.html
[14e] http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/0162.html
17:30 Adjourn
Raw IRC log: http://www.w3.org/2002/11/11-ws-desc-irc
Received on Friday, 15 November 2002 13:02:14 UTC