- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 21 Apr 2002 22:01:20 -0700
- To: Tim Bray <tbray@textuality.com>
- Cc: www-tag@w3.org
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