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

RE: Reqs extracted from xmlp req list

From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
Date: Tue, 12 Mar 2002 18:56:02 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D58FEB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
Cc: "FABLET Youenn" <fablet@crf.canon.fr>, <www-ws-desc@w3.org>
Jean-Jacques, comments below in [[square brackets]]. --Jeff

-----Original Message-----
From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr] 
Sent: Tuesday, March 12, 2002 3:04 AM
To: Jeffrey Schlimmer
Cc: FABLET Youenn; www-ws-desc@w3.org
Subject: Re: Reqs extracted from xmlp req list


Thanks for having examined these proposed requirements with such
attention. Overall, I agree with your comments. Some specific comments

I apologize for this late response.


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...
[[jeffsch: I don't think this makes the bar to be an explicit
requirement. If you feel otherwise, please raise it during a

> 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."
[[jeffsch: I think this is adequately covered by R013.]]

> 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/
[[jeffsch: I don't disagree, but I'd rather not include scenarios as
requirements given that we have a scenarios document. I expect that when
we're happy with the scenarios, we'll go back to the requirements and
make sure the two are in sync. Are you OK with that plan?]]

> (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." ?
[[jeffsch: Is this the requirement: must be able to bind each message
within an operation to distinct transport and wire formats?]]

Sorry again for the late response.

Received on Tuesday, 12 March 2002 21:59:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:37 UTC