Re: Web Service Architecture Usage Scenarios editors copy available

<Hat xmlns:wsawg="http://w3.org/2002/ws/arch" type="wsawg:chair" mode="off">

Some comments.

Mark Baker wrote:

<snip/>
 > binding.  Also, the company symbol would be removed from the body and
 > reflected in the URI that the PUT was invoked upon, for example;

I'm not sure that I agree with this. URIs are meant to be opaque. They
identify a resource, but they don't necessarily themselves carry
any semantic quality beyond the scheme and authority. Thus, the
example you cite below, while suggestive of carrying some meaning
(that the URI identifes a resource that is the stock quote for
a firm called "BigCo") could just as easily have been:

	http://example.com/foo/bar
or
	http://example.com/hsfakfuwli324oyhll

Sure, the authority knows to map this URI to the resource that
happens to be BigCo's current stock quote, but that doesn't help
the holder of the URI without some additional, external help.
In addition, absent the clue that the URI might provide, the
representation on its own is meaningless if all it is is the
quoted price.

Consider that HTML pages have metadata such as <title/> as part
of the resource representation, why wouldn't the StockQuote include
	<r:Symbol>BigCo</r:Symbol>
?

 >
 >   http://example.org/stockquotes/BigCo/
 >
 > 2.4.*; these are RPC examples, which are necessarily inconsistent with
 > Web architecture.  I suggest removing them.

I disagree. People have been doing RPC equivalent things with
the Web since its inception. The world has not come to a screeching
halt as a result. I'll grant that it is possibly sub-optimal
use of the Web, but the infrastructure doesn't preclude such
usage, nor for that matter does the architecture. There's a
reason that the HTTP RFC says things like SHOULD when it
discusses use of GET and POST.

"You can lead a horse to water..."

Don't misunderstand, I'm sympathetic to what you are saying, but
also recognize that it is an imperfect world in which we live
and we cannot preclude that people will use technologies in
ways that might seem inconsistent with their design.

 >
 > 2.10.2; as for 2.1.2, these examples violate Web architecture by
 > specifying a function in the SOAP body.  As this method is a retrieval
 > method, presumably without side effect, they should be using HTTP GET.
 > We could either remove them, or if we want to identify the need for a
 > SOAP GET binding, we could defer to it for what the example would
 > look like.

I think that rather than remove the use case, having it compared/contrasted
with a GET binding use case, such that the benefits can be established, etc.
would be a possibly better approach.

 >
 > 2.15.2; even though the details of these messages are not important to
 > the example, I believe that all examples should be Web architecture
 > friendly.  Perhaps replace it with my corrected example from 2.1.2
 > above.
 >
 > 2.25.2; as for the other examples, "StockNotificationSubscription" is
 > a function name, and therefore not Web architecture friendly.  There
 > are at least two possible ways to implement this functionality in a Web
 > architecture friendly manner; if you're interested, I can let you know.

</Hat>

Please do propose a use case/scenario that describes this.

<Hat xmlns:wsawg="http://w3.org/2002/ws/arch" type="wsawg:chair" mode="off">

 >
 > The other examples are great.  Many include no body, only headers, and
 > those appear fine to me.  I did check them to make sure that they
 > weren't stateful; none appeared to be.
 >
 > Thanks again.
 >
 > MB
 >

Cheers,

Chris-not-the chair

</Hat>

Received on Thursday, 2 May 2002 15:22:25 UTC