- From: Mark Baker <mark.baker@canada.sun.com>
- Date: Tue, 09 Jan 2001 10:37:04 -0500
- To: Aaron Swartz <aswartz@upclink.com>
- CC: Joshua Allen <joshuaa@microsoft.com>, "'Kurt Cagle'" <cagle@olywa.net>, XML-DIST-APP <xml-dist-app@w3.org>
Aaron Swartz wrote: > > Joshua Allen <joshuaa@microsoft.com> wrote: > > > Extracting the information from the HTML would be pretty tedious, though, and > > prone to breaking. Eventually you would want a generic sort of technique that > > service providers and developers could all count on so that each "hookup" > > wouldn't have to be negotiated individually. At that point you would just > > invent XML-RPC :-) > > Or just plain XML? Or plain text? We can still make HTTP GET requests for > XML, you know. ;-) Amen! > > So SOAP will often be used for synchronous calls to an individual > > method, but I also hope it will be used just as much for asynchronous > > message passing that may or may not invoke one or more actions on the > > receiving end. > > I totally understand this -- SOAP had benefits and plain HTTP has benefits. > That's not the question. The question is what is the XP's position on the > issue. See http://www.w3.org/2000/09/XML-Protocol-Charter My reading of that says that we do both. > Pretty much, yeah. But also the fact that most SOAP implementations live at > a specific URI. While SOAP may be able to be sent in many different ways, > the fact of the matter is its generally being done using POSTs to a single > URI receiver. > > Many folks feel this is wrong. What does the WG feel? Well, as long as SOAP is used to cleanly *extend* POST semantics, is there a problem with it not having a GET binding? I understand your point, but sometimes POST *is* the right answer. MB
Received on Tuesday, 9 January 2001 10:34:37 UTC