- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Tue, 26 Mar 2002 15:06:16 -0500
- To: Paul Prescod <paul@prescod.net>
- CC: www-tag@w3.org
Paul, Paul Prescod wrote: <snip/> > > I'll repeat my challenge one more time. Can you point me to a single > public SOAP+HTTP service that adheres both to the web architecture > principles described here: Currently, I'm unaware of any SOAP 1.2 (XMLP) based public services. > > a) http://www.w3.org/DesignIssues/Axioms.html > > and the semantics of HTTP described here: > > b) http://www.w3.org/Protocols/rfc2616/rfc2616.html Again, what is it about the existing SOAP HTTP binding in the SOAP 1.2 Part 2: Adjuncts specification that you claim is "broken" with regards to the use of the HTTP POST method as described in b)? It is the absence of specification for the use of HTTP GET (and possibly others) method? If so, please see: http://www.w3.org/2000/xp/Group/xmlp-issues.html#x133 To be honest, I think that the binding is if anything, "not taking full advantage of the web", but that doesn't mean it is "broken". > > I'm just asking for a single realistic example to get the ball rolling. > We're dancing around this issue. SOAP supporters keep blaming the > developers. "It isn't SOAP, it's the people using it." I think that that > is disingenuous. If you know today that the vast majority of uses are > going to be broken, to the extent that we can't find a single one that > is not, then where does the blame really lie? > > >>Putting "compatibility with web architecture" aside, the issue >>is actually one of charter and scope[1]. Defining a "compact encoding" >>such as URI encoding of a SOAP message is expressly out of scope >>for the XMLP WG as originaly chartered. >> > > That's a procedural explanation for a technical failure. But the TAG is The process exists for a reason. > about the technology. To be honest I'm not nearly as interested in > understanding why the technologies do not work together as in figuring > out how they can be made to work together. > > Paul Prescod > >
Received on Tuesday, 26 March 2002 15:07:14 UTC