Paul Prescod wrote:
<snip/>
> Reasons to Fear XML Envelopes
>
> An "XML Envelope" is a package that wraps up XML headers with an XML
> body or "payload"
> * Pathetic at handling non-XML (especially binary) payloads.
Yes, but it wasn't particularly designed for that. The problem is easily
addressed using MIME, as demonstrated by the SOAP With Attachments spec.
So what's the problem with MIME?
> * Demonstrably [1]not [2]sufficient for non-binary data.
How so? It works quite well with most data. And if you need to transmit
an arbitrary document, you can use SOAP With Attachments, which just
uses MIME. What's wrong with MIME?
> * Binary data solutions not-standardized and perhaps
> patent-encumbered.
What "binary data solutions" are you refering to? AFAIK, SOAP just uses
Base64 and/or MIME (SOAP With Attachments) for binary data. Since when
are Base64 and MIME not-standardized and perhaps patent-encumbered?
> * If the payload is XML, it might be a complete document with a
> leading XML declaration. That isn't legal so it would have to be
> treated as if it were non-XML.
Which is really not a problem when you are more concerned with conveying
data structures rather than opaque documents. Who said SOAP has to be
the One True Way of transmitting all content on the web? There are a
large class of problems well suited to the sort of XML processing model
that does namespace-based dispatching on modular element structures,
rather than viewing things in terms of a monolithic document structure.
SOAP can serve that class of problems quite well.
> * There are all sorts of hairy issues relating to the
> interpretation
> of (e.g.) xml:base, namespaces in general, XPointers that point
> to
> the root etc. You must keep all of these in mind doing XML
> processing of documents that use XML for both envelope and
> payload.
Again, only an issue if you want to transmit opaque documents -- and
easily worked around (if you need to that) by using SOAP With
Attachments.
> * Merging and splitting payload from envelope requires XML
> processing which is more expensive than MIME processing.
Most of the systems I've seen interpret the entire infoset of the SOAP
message at once. They don't extract a "document" from the body. Again,
you are just thinking of this in terms of document-centric models. There
are other perfectly valid models for XML processing that SOAP suits just
fine.
> * Envelopes cannot transmit potentially malformed data without
> encoding it somehow.
Or using SOAP With Attachments.
> * Tends toward conflation of protocol and payload.
>
> Problems seem major.
>
> Reasons to Love XML Envelopes
>
> * Trendy?
> * Dig the radical recursiveness of it all?
> * Ability to handle the whole message as one unit with XML
> processing tools like XPath and XSLT.
> * Others solicited!
The use of XML is quite convenient for a broad class of applications, in
particular applications interested in processing modular data structures
(which can be modeled with XML Schema) with some associated contextual
info (such as authentication info) in a loosely coupled fashion. There
are certainly large classes of problems that are not well suited for
SOAP.
Certainly, the notion of Web Services needs to expand and evolve to more
appropriately embrace web architecture. But I still see the SOAP
envelope as a quite useful construct for a large class of problems. All
the arguments against it seem to be rooted in a document-centric world
view, or a fear that SOAP will completely take over and lock out other
messaging schemes or simple HTTP GETs. The latter seems to me to be a
bit paranoid, although I can see some of that happening with all of the
hype around SOAP these days. This will need to be combatted by education
and articulation of a richer vision of web services that embraces web
architecture. Beyond that, though, I think people need to learn to
accept that there are very divergent models of XML processing that are
well suited to different classes of problems. It would be mistake, IMO,
to think that all of these must be brought under the umbrella of a
single all-encompassing standard. Many have cited the 80/20 rule before
on this list. I'd go even further and say that sometimes trying to hit
that 80 mark may be too costly, but 60/40 -- or even 40/60 -- may still
provide enough benefit to be worth the effort. I don't see that proving
there are large classes of problems it does not solve really invalidates
SOAP's approach, unless it can be demonstrated that there are *not*
large classes of problems it can solve or that there is an equivalently
simple approach that addresses a superset of requirements.
No document-centric approach, though, can fully address the same set of
requirements that SOAP addresses. Any superior solution must just as
effectively be able to support the same sort of modular,
namespace-centric processing models that the SOAP envelope supports.
