Re: SOAP and the Web architecture

[Paul Prescod]
> That's another way but now you are trading off human-readability which
> is a major advantage of both URI's and XML (that's why we don't use
> UUIDs and ASN.1!). I think a=b&c=d would be a minimized format. The
> serialization would be an expanded one.

> Just as there is a canonical XML, canonical Unicode, etc. there should
> be a canonical section 5.
I've been arguing for this for a long time. Creating a canonical form for
requests via a GET message is still the only effective away that low
bandwidth devices can employ web services currently, especially if you
negate the arbitrary distinction that web services are machine-to-machine
content while GET/POST involves human interaction. To me it makes a great
deal more sense to provide both an HTTP and SOAP mechanism for making at
least some web services calls (HTTP was, after all, intended initially as an
RPC mechanism in the first place, if you read the histories), placing the
requirement of implementing the dual services on the server vendors. Over
time, as new devices are introduced that have SOAP clients built in then you
can effectively deprecate the older HTTP architecture once a critical mass
of such devices are out there, but otherwise you make the adoption of web
services through SOAP limited to a very narrow market, primarily driven by
e-commerce.

A canonical section 5 definition makes a great deal of sense. It means
losing some anonymity of properties -- you have to explicitly define certain
properties (the first "method" property is defined as the canonical method,
for instance) -- but is this really any different than creating a schema
namespace? If you have an existing map, then it becomes a trivial process of
mapping this canonical section 5 to a SOAP message for subsequent
transmission to intermediaries.

-- Kurt Cagle

Received on Tuesday, 28 August 2001 16:33:35 UTC