Loading ...
Sorry, an error occurred while loading the content.

5226Re: [decentralization] Re: xml protocols and transport bindings

Expand Messages
  • Paul Prescod
    Feb 3, 2002
      Clay Shirky wrote:
      > ...
      > 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, ...)

      I understand you are acting as a reporter, not a promoter, but your
      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
      XML documents!

      * 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, ...)
      Envelope: MIME/RFC822
      Transport: TCP

      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.

      > 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.

      XML is inherently both transport and data-format insensitive. So what
      value is the "encapsulation" adding?

      > Thus much of the bloat of SOAP comes not from designing it to do
      > certain things, but from bending over backwards not to design it to do
      > *only* certain things.

      I would say, rather, that the bloat of SOAP came from taking a spec
      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

      Paul Prescod
    • Show all 20 messages in this topic