Raw minutes for Tuesday afternoon

W3C WS Desc WG F2F Meeting
June 10-12, Paris, France

Minutes for Tuesday afternoon (6/11/02)

Discussion on MEPs (issue 2a on the agenda [1])
-----------------------------------------------

Jean-Jacques Moreau gave a presentation on SOAP 1.2 MEPs [2]

Jonathan: what's our position on MEPs?
Jacek: we should define what an operation is
Jacek: we should discuss this issue at this F2F
Philippe: SOAP MEPs are at the protocol level, WSDL ones are at the application level
Sanjiva: let's read what the WSDL spec says about this
Sanjiva: (after reading the spec) operation types are just like SOAP MEPs
Glen: SOAP MEPs are described at the abstract level
Glen: it was done by the XMLP group simply because it was needed there and there was no arch group at the time
Philippe: issue: there is no one-way SOAP MEP
Jean-Jacques: there is currently no way to advertise SOAP features in WSDL
Philippe: this wg doesn't have to go beyond one-way and req-resp MEPs
Jonathan: we need a concrete proposal, and I don't see one right now
Sanjiva: someone should come up with a proposal
Jeff M.: let's have the conversation now and use that as a basis for a proposal
(discussion) what is an operation?
Jacek: abstract model proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0153.html
Jacek: operation has a set of messages; three kinds of messages: input, output, fault
Jacek: operation = ordered set of messages
Jeff M.: operations are abstract, how can we reuse SOAP MEPs?
Glen: SOAP MEPs are generally applicable
Jeff M.: MEPs in the WSDL context are not the same as SOAP MEPs
Glen/Jeff M.: the SOAP MEPs is an instance of a generalized MEP notion
Glen: advantage of using the same framework: it's easier to create/share tools
Jacek: in WSDL we don't talk about multiple nodes, just one
Jeff M.: we need only solve the WSDL problem, not the universal one
Sanjiva: Glen's proposal was to replace the fixed set of MEPs in WSDL with a more general one
Glen: request-response is simple, other MEPs have more complex rules
Sanjiva: you can do this with extensibility in WSDL
Jacek: (drawing on the whiteboard)
Glen: I don't want to see different groups build their own concepts instead of using a common framework (MEPs)
Dietmar: WSDL describes interfaces, SOAP describes messages
Sanjiva: but SOAP is not metadata (about messages)
Gudge: some other people would like WSDL described from the client point of view, not the server one
Jeff M.: we need proposals
David B.: we need to adopt one way to talk about it, so we have a common language
David B.: for example, adopt the web service's point of view -- it's only a convention
keith: in WSDL transmission primitives, it's the point of view of the endpoint
Tom J.: tools interpret the WSDL from the appropriate point of view depending on what the user is doing
Tom J.: most commonly, it's the client's POV
Gudge: +1 to David B.'s proposal -- let's reduce confusion
Gudge: don't use request/response, always use input/output
Jonathan: there is consensus to adopt david's terminology (at least for this discussion)
David B.: Here is my proposal for using consistent input/output terminology: http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0157.html
Glen: close the "extensible message patterns" because there is no consensus and it can be done with extensibility
Glen: BUT can't we keep it open for now?
Jonathan: eventually we have to close all issues
Jonathan: we can always reopen issues later

[RESOLUTION] close issue 2a, saying that it can be done with extensibility

Glen: we should coordinate across WS Activity wgs
Sanjiva: issue "issue-operation-patterns" closed: open-ended extensibility model enables the description of arbitrary operation patterns (this was an issue from Prasad)
Jonathan: there is another issue on this, the one raised by Glen isn't listed yet
Jonathan: the issue we closed is the one Glen raised
Jonathan: now let's look at Prasad's issue
Jacek: it's a separate issue
Jacek: allow arbitrary sequence of input/output/fault messages inside an operation
Jacek: (draws on the whiteboard)
Gudge: what is the difference between this issue and the previous one?
Jacek: they are the same (or at least we can solve and close both of them at the same time)
Jeffrey S.: if you really want to express this you can use an orchestration language
David B.: is there harm in allowing multiple input/output elements?
Jeffrey S.: if something is declaratively specified, there's going to be an expectation that all processors understand it
Jeffrey S.: on the other hand, if we use a QName, the expectations will be different
Jeffrey S.: if we go down this declarative way, we may have to invent an orchestration language
Jeff M.: Shouldn't that be a separate effort?
Jacek: we can leave patterns beyond one-way and req-resp to other specs
Sanjiva: updated the resolution of the issue named "issue-operation-patterns" to incorporate this feedback

Jean-Jacques: are we closing issue 26 too?
Jean-Jacques: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html
Jonathan: issue 26 is a binding issue
Gudge: we should leave it open
[agreement] leave 26 open

Discussion on WG's schedule
---------------------------

Jonathan: (slide presenting the schedule)
Jonathan: six telcons left before the september f2f
Jonathan: the ratio of issues to telcons is pretty high
Jonathan: make the process more efficient
IT: Issue Team
Kevin: many issues should be easy to close
Jacek: it's better to have one issues list
David B.: have links from the specs to the issues list
Jonathan: xmlp group prioritized the remaining issues
Jean-Jacques: increase the bandwidth by having non-editors come up with issue resolutions too

Discussion on removing solicit-response and output-only operations (issue 2c on the agenda [1])
-----------------------------------------------------------------------------------------------

Jonathan: one remaining issue: should we remove solicit response?
Jonathan: issue: remove solicit-response and output-only operations
Jeffrey S.: what does it mean to have solicit-response ops with a HTTP binding?
Jacek: solicit-response and output-only are used to describe an interface that a service will need (as opposed to provides)
Jonathan: let's take a strawpoll
Jonathan: the "remove them" option wins 11-4
Jeffrey S.: eliminating sol-resp/out-only you end up with two port types that will always be used together
Philippe: I don't understand how a solicit-response can work if the solicited is not a web service itself. in other words, the one who asks for a solicit-response act as a client, ie, this is a 
request-response.
Glen: sol-resp/out-only is orchestration
Sanjiva: we should remove them because: (1) no bindings deal with sol-resp/out-only; (2) there are multiple interpretations for them (callback, event, ...)
Jacek: major use case for sol-resp/out-only is callbacks
Jeffrey S.: need to describe all messages going in and coming out of a service
Jeffrey S.: if we can't use WSDL to do this, time for a new working group
Jeffrey S.: we should be able to take two web services, compare them and see if they are compatible
Jeffrey S.: there are multiple ways to do it
Sanjiva: should rephrase the requirement using operations instead of messages
Glen: using portType QNames is the way to go (analogy with programming languages)
Jeffrey S.: there's going to be cases in which there is no shared WSDL between the two services
David B.: (drawing on the whiteboard)
Gudge: you can't do it without sol-resp unless you have multiple WSDL files
Jacek: you can use "service provides..." and "service requires..."
Jonathan: WSFL and XLANG authors told us they use sol-resp/out-only but they are going to remove those uses
(big discussion ensues)
Jonathan: Jacek will come up with a proposal; jeffrey will write up his requirements

[ACTION] Jacek to write a concrete proposal
[ACTION] Jeffrey to write up his two requirements

Jonathan: we'll discuss this more tomorrow afternoon
Jonathan: new strawpoll
Jonathan: result: still more votes for removing them, but with a smaller margin than before

References
----------

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0045.html
[2] http://www.w3.org/2002/06/SOAPWSDL.html

Received on Wednesday, 12 June 2002 05:38:11 UTC