- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Tue, 12 Mar 2002 12:04:27 +0100
- To: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- CC: FABLET Youenn <fablet@crf.canon.fr>, www-ws-desc@w3.org
Jeff, Thanks for having examined these proposed requirements with such attention. Overall, I agree with your comments. Some specific comments below. I apologize for this late response. Jean-Jacques. Jeffrey Schlimmer wrote: > The WSD requirements must include usage scenarios that describe how WSD > is used in various environments. The set of usage scenarios must > represent the expected range of WSD's use. The scenarios must be used as > design cases during the development of WSD, and it must be possible to > determine whether or not the WSD design enables each scenario. In > addition, the usage scenarios are intended to help a technically > competent person understand the role of WSD. > [jeffsch: Use Cases Waqar is editing.] I agree this requirement looks like it's being met already, but we may still want to have the requirements anyway... > Simple applications are often characterized by message exchange patterns > such as one-way (or event), and two-way (or > synchronous) request response interactions. The specification should > make such simple exchange applications as easy as possible to create and > to use. > [jeffsch: DR036: The Working Group will define a mechanism which will > allow a Web service to describe the following set of operations: one-way > messages (to and from the service described), request-response and > solicit-response, as described in WSDL 1.1's port types.] Correct, although I don't think DR036 covers the last sentence: "The specification should make such simple exchange applications as easy as possible to create and to use." > The WSD specification must consider the scenario where an XMLP message > may be routed over possibly many different transport or application > protocols as it moves between intermediaries on the message path. > [jeffsch: Use Cases Waqar is editing.] Yes, but I'd still think we need this requirement, possibly with the following change: s/must consider the scenario where/must support the scenario where/ > (Not sure if this one is relevant... > it might nevertheless raise some issues. > Like should a WS describe some kind of message path for its response? > What about an answer that needs a different protocol than the request ? > Should a WS describe that it will answer directly to the initiator or > the last intermediary? (important if we would like streaming a response > (implementation stuff ?))). > [jeffsch: These feel out of scope of WSDL, and more in the scope of > things like WS-Routing / WS-Referral:<cut/>] Ok, what about rewording the requirement as follows: "Must be able to describe accessible through one protocol and returning an answer through a second protocol." ? Sorry again for the late response. Jean-Jacques.
Received on Tuesday, 12 March 2002 06:06:16 UTC