RE: Issues 12 & 192 (long)

> In the "chameleon use" of SOAP, the relationship between SOAP and HTTP
> is not one of layering, but one of extension (i.e. both work together
at
> the application layer).  

If SOAP were a natural extension of HTTP, there would be
examples where the same resources would engage in both
HTTP web activities and SOAP-based activities in some way.

Look, however, at the use cases proposed.
If there were a requirement to do this integration,
it would show up as criterial for some use case.
The use cases I can find are contained in the "Requirements"
document:

  http://www.w3.org/TR/xmlp-reqs/#N2690 

other use cases discussed on this list:

 http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0271.html
 http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0108.html

and the XML protocol charter
  http://www.w3.org/2000/09/XML-Protocol-Charter
(getStockQuote and validateCreditCard) along with
references to SOAP, XML-RPC and WebBroker.

In every single case, there is no justification for
a "chameleon use" model. There is no relationship
established between the use case and the ordinary HTTP
access of resources using GET, Accept, cache control,
etags, last-modified, etc. 


So your theory about "chameleon use" isn't
supported... of course you could, but why would you?

Contrast this situation with WebDAV, where at least it
is argued that WebDAV operations are a natural extension
into 'authoring' of the ordinary access to the same
objects via web browsing.

If SOAP were really a "chameleon use", there would be
some connection between SOAP and WebDAV, for example.
You would integrate SOAP with the rest of the mechanisms
of HTTP, including cache controls, content negotiation,
Vary headers, last-modified and the rest. You would integrate
SOAP responses with all of the mechanisms of HTTP, instead
of this one little bit of "500" vs. "200" error responses.
There's no basis for claiming that anyone has actually
done this integration.

>             In this use, SOAP very closely resembles
> PEP[1], though of course the envelope and processing model remain
> independant of any specific application protocol.
> 
>  [1] http://www.w3.org/TR/WD-http-pep 

One of the main problems with PEP was that there were
no compelling use cases; the justification given was
of the form "People are already doing this so we should
provide a standard mechanism for doing it", without
any justification for why HTTP "extensions" made more
sense than HTTP "tunneling". So you can't reduce this
to a previously-unsolved problem, it gives you no leverage.

Larry
-- 
http://larry.masinter.net

Received on Sunday, 31 March 2002 20:36:03 UTC