5226Re: [decentralization] Re: xml protocols and transport bindings
- Feb 3, 2002Clay Shirky wrote:
>I understand you are acting as a reporter, not a promoter, but your
> Here's the problem: the Web Services stack is more subdivided than the
> Web stack.
> The Web Web Services
> Encoding (HTML) Data Format/App Logic (e.g. OFX, RSS...)
> Transport/App Logic (HTTP) Envelope (SOAP, XML-RPC)
> Encoding (XML)
> Transport (HTTP, IM, SMTP, BXXP, ...)
picture gives rise to a bunch of questions:
* Doesn't the Internet already have an envelope format?
* XML-RPC is not promoted as an envelope...embedding of non-XML-RPC
information is possible but not exactly a central part of the spec.
* Is there virtue in using XML as an envelope? I can certainly see
virtue in XML *headers* but why would you want the envelope to be XML
when XML is so poor at embedding binary and ... even poor at embedding
* If SOAP is an envelope then why does it need the "encoding" and RPC
bits at all? Could we just admit that SOAP as it is envisioned today is
about as far as you can get as SOAP as it was envisioned by Box, Winer,
etc? Is it just politics that the spec of today and the spec of several
years ago still live cojoined like siamese twins?
* Where do DIME and SOAP+Attachments fit in?
Anyhow, I would draw the Web part of the picture as:
Data Format: (HTML, PDF, JPEG, PNG, SVG, OFX, RSS, ...)
Admittedly the Web world does not use a single encoding. If XML were
better as an envelope format then it might be attractive to try to use
it as an uber-encoding. But XML is poor as a generalized envelope. XML
advocates do NOT embed binary data in XML files. That isn't the point of
XML. MIME does an excellent job already and people have been using XML
with MIME since it was called SGML.
>...XML is inherently both transport and data-format insensitive. So what
> Now you can argue, as the RESTanians do, that this is The Wrong
> Answer, and I'm sympathetic to that view, but if your goal is
> something that looks like the stack above, you need just enough
> structure to encapsulate XML into something that is both transport and
> data-format insensitive, without adding so much structure that it
> forestalls undreamt of uses.
value is the "encapsulation" adding?
> Thus much of the bloat of SOAP comes not from designing it to doI would say, rather, that the bloat of SOAP came from taking a spec
> certain things, but from bending over backwards not to design it to do
> *only* certain things.
meant to do A and porting it to problem B "for the sake of Momentum." Of
course as I've said above, I'm not convinced that problem B actually
exists, because the Web already has decent envelopes. And XML-RPC is
surprisingly good at solving problem A, RPC.
There does exist sub-problem C, which is that MIME headers are very
painful for structured information and don't have nice syntaxes for the
MustUnderstand stuff etc. But SOAP 1.2 is a hell of a hammer for that
- << Previous post in topic Next post in topic >>