W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2002

Re: Reqs extracted from xmlp req list

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Tue, 12 Mar 2002 12:04:27 +0100
Message-ID: <3C8DE0BA.56E1CD4E@crf.canon.fr>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:19 GMT