5233Re: [decentralization] Re: xml protocols and transport bindings
- Feb 4, 2002
> I understand you are acting as a reporter, not a promoter, but yourOh yes.
> picture gives rise to a bunch of questions:
> * 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 seeSee below.
> 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 RPCGood question. This is Lucas's argument in part, namely that the
> 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,
phrase 'human readable' only makes sense for the current SOAP spec for
small values of 'human' and 'readable', and that may well getworse
> * 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:Note that you do not have app logic in here, a critical feature, since
> Data Format: (HTML, PDF, JPEG, PNG, SVG, OFX, RSS, ...)
> Envelope: MIME/RFC822
> Transport: TCP
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 wereHence SOAP.
> 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 theYep. I'm betting some XML+MIME solution becomes standardized in 1.2.
> 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 whatStandard Header+body separation, and better structure as a generalized
> value is the "encapsulation" adding?
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
- << Previous post in topic Next post in topic >>