Re: No consensus on draft findings on Unsafe Methods (whenToUseGet-7)

On Sunday, April 21, 2002, at 09:36  PM, Tim Bray wrote:

> Mark Nottingham wrote:
>
>> The main issue is that it can't be called a binding - because it 
>> doesn't in fact provide an abstract, transparent messaging substrate 
>> for SOAP; instead it severely limits it, by imposing:
>>  * RPC only
>>  * request-response MEP only
>>  * Section 5 encoding only (and references would need to be addressed)
>>  * no Headers (except for those that can be abstracted out as HTTP 
>> features)
>>  * no support for SOAP envelope versioning, etc.
>
> So what's your point?  I've been explicit that this only works for the
> subset of SOAP transactions for which a GET method semantic makes
> sense, and is not trying to support all or even very much of the
> functionality of SOAP.

I think my point was clearly made; from SOAP's perspective, 
accommodating GET isn't a clean fit, because of the restrictions that 
that implies. GET doesn't fit well into SOAP. One of the goals of SOAP 
is to be transport-agnostic as much as possible; that's difficult with 
GET.


>> XMLPWG didn't show much interest [2] in this approach, and that isn't 
>> surprising; it doesn't fit cleanly into SOAP, and the use cases, 
>> although evident now (because so many people see SOAP as just 
>> RPC-using-XML-over-HTTP), are pretty uninteresting in the face of 
>> where most vendors want to take SOAP. I've already spoken about the 
>> dubious value of HTTP caching to SOAP, so the only remaining tangible 
>> benefit is linking/bookmarking.
>
> It's precisely the job of the TAG to worry about web architecture,
> especially when it appears that other WGs are blowing it off.  The
> response to issue 133 is not exactly comforting.

I agree with the sentiment (and pursued a better resolution at the 
time), but it's hard for WGs to respect the Web architecture when it 
isn't documented (at least in a W3C-recognized way), and when their 
charters don't explicitly mandate it, despite the fact that this issue 
could have been foreseen. Hopefully the TAG will successfully address 
both of these shortcomings in the future; I'd rather see it be proactive 
than become the WebArch police.

Thanks,

--
Mark Nottingham
http://www.mnot.net/

Received on Monday, 22 April 2002 01:01:22 UTC