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

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

Expand Messages
  • Clay Shirky
    Feb 4, 2002
      > I understand you are acting as a reporter, not a promoter, but your
      > picture gives rise to a bunch of questions:

      Oh yes.

      > * Doesn't the Internet already have an envelope format?

      Yes but (as I understand the argument) not one that includes data
      types or uniform serialization. Deciding whether SOAP is an
      improvement in those areas is left as an excercise for the reader.

      > * 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!

      See below.

      > * 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?

      Good question. This is Lucas's argument in part, namely that the
      phrase 'human readable' only makes sense for the current SOAP spec for
      small values of 'human' and 'readable', and that may well getworse
      with 1.2.

      > * Where do DIME and SOAP+Attachments fit in?

      DIME is an attempt to deal with SOAP1.1's limitations, which you noted
      above, in carrying binary data, as well as the need to encapsulate
      arbitrary XML fragments, without jamming the new features into SOAP

      SwA is an attempt to solve the binary problem with MIME, in SOAP
      itself, and not in a transport* mechanism.

      (* Again, transport as in FTP, not as in TCP. DIME is meant to run
      directly over TCP/UDP if needed.)

      Frystyk Nielsen just published a new IETF draft on DIME, which I have
      not digested yet, but its here:


      > 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

      Note that you do not have app logic in here, a critical feature, since
      it is HTTP-as-app logic that creates much of its interop. If there
      are only a handful or truly primitive calls -- GET, PUT, POST, etc --
      then coordination becomes much easier.

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

      Hence SOAP.

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

      Yep. I'm betting some XML+MIME solution becomes standardized in 1.2.

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

      Standard Header+body separation, and better structure as a generalized
      envelope.. As you note, RFC822 already provides a version of this, but
      its not in XML, so you can't turn an XML parser loose on 822 headers.

      Whether this is worth the tsouris is again left as an excercise for
      the reader.)

    • Show all 20 messages in this topic