Paul Prescod wrote:
<snip/>
> I have no problem with MIME. In my mind, MIME is the alternative to XML
> envelopes. The fact that you still need MIME sometimes when you use XML
> envelopes serves as evidence to me that MIME should just be the default.
It seems to me the default should be the one that addresses the broadest
number of use cases.
MIME multipart is unarguably the better approach for transmitting
documents. But XML is well suited for modeling structured information of
arbitrary complexity. If I'm interested in exchanging structured
information over the web and am not concerned with exchanging entire
documents, and I know that I am going to need to parse an XML message
either way, then modeling the relevant components of information as
element structures wrapped in element structures scoped to a different
namespace is more convenient and useful than modeling them as separate
XML documents in a MIME multipart envelope. The latter just means I now
have to parse 2 document formats instead of one, even though I'm
deriving no benefits from MIME.
If the use case of exchanging documents were the dominant use case for
Web Services, I would agree that MIME should be the default. But I'm
inclined to believe that the overwhelming majority of use cases for Web
Services will be those just interested in exchanging structured
information in a fashion that fits well with the SOAP approach.
> SOAP with attachments: "IBM may own patents or patent applications which
> apply to the SOAP Attachments specification being submitted to the W3C.
> If implementation of a W3C standard based on the SOAP Attachments
> specification requires the use of IBM patents, IBM will grant, upon
> written request, a non-exclusive license under such patents on
> reasonable and non-discriminatory terms."
That's unfortunate, but I think it's easily resolved. SOAP With
Attachments just used MIME and hypermedia. If IBM claims a patent on
those two, we are all in trouble. If, on the other hand, they just claim
patents on a particular covention for using MIME and hypermedia, I'm
sure that can be easily worked around. (For that matter, I would think
the patents to be rather difficult to defend.)
>
> DIME: "The IETF takes no position regarding the validity or scope of any
> intellectual property or other rights that might be claimed to
> pertain to the implementation or use other technology described in
> this document or the extent to which any license under such rights
> might or might not be available; neither does it represent that it
> has made any effort to identify any such rights."
I'm less concerned with DIME. I doubt it will be a dominant format on
the web. But who knows. However, this is a problem that any spec can run
afoul of. This is not a technical issue with DIME's approach. It simply
simply points to the deeper problem of conflict between intellectual
property rights and the evolution of open standards. This same problem
has arisen with several W3C specs.
> That will change as people start to use SOAP headers and have a
> requirement to process a single header (perhaps for dispatching) before
> they do anything with the body. This ability to target headers (and make
> them mandatory) is the primary advantage of SOAP headers over MIME
> headers.
>
> * http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0128.html
I've done this many times without any problems. So long as the headers
section appears before the body, you can even do this in a single pass
with a SAX processor. It only becomes a problem when you want to pass
the entire envelope around among different applications across the
network (or at least in different process spaces), with applications
plucking out only relevant headers, while possibly inserting additional
headers. I've heard this scenario depicted before, but personally I'm
highly skeptical that this will be a dominant usage pattern for web
services. Perhaps I'm simply biased by my own experiences, but I find
this vision of web services to be a bit dubious. I can't help but think
that coordination between web services will be managed by applications
that process entire message envelopes, and based on that information
construct specific messages targeted at other services, not handing the
entire envelope around the network like a baton.
But who knows. If this really becomes the predominant model for web
services, MIME probably would be better. I'm just skeptical that this
will be the case.
> How would using MIME instead of XML envelopes prevent you from
> "processing modular data structures with ... in a loosely coupled
> fashion." I've tried to demonstrate that using MIME allows you to be
> MORE loosely coupled by allowing a single intermediary to work with a
> header or the body without worrying about anything else in the message
> that might confuse it.
Well, so long as I can use XML to model the individual components of
information, it doesn't stop me. But it adds extra complexity while
providing no benefit. Unless the SOAP envelope approach can be
demonstrated to be harmful, I don't see any compelling reason to force
my application to have to deal with 2 document formats (MIME multipart
and SOAP), when one will do just fine.
> The job of a protocol envelope is to separate things. MIME just seems to
> do a better job of that than XML envelope strategies.
Only when the things you are separating are documents. If the things you
are separating are components of structured information that is easily
modeled as XML fragments, XML envelopes can work just fine. More
importantly, since MIME just deals with opaque documents, I can think of
only a tiny fraction of the use cases for web services where MIME would
suffice; I'd pretty much always have an XML document in there. But I
find the overwhelming majority of use cases with which I have
experience can be quite adequately addressed with an XML envelope. I
don't see a compelling argument for forcing all of these applications to
have to support 2 document formats when just one of them can suffice for
the overwhelming majority of use cases. The only danger, here, is
misguided developers misusing the solution, or applying it to ill-suited
use cases. But that happens with every technology.
> Well I don't think anybody has really demonstrated benefits to the XML
> envelope approach. Until they do why talk about segmenting the market
> into things that MIME is good for and things that XML envelopes are good
> for. You segment to meet different requirements. So far, there are no
> different requirements.
I think there are some fairly well-defined requirements, here. My
requirement is to exchange structured information over the web. MIME
does not accomodate that. MIME just models opaque documents. A MIME
multipart envelope is just an unstructured collection of opaque
documents. XML is perfectly suited to modeling structured information of
arbitrary complexity. It's shortcoming is that it is not well suited as
a container of documents.
Given that MIME cannot deal with arbitrarily complex, structured data,
it clearly does not cut it as a complete solution. When we are talking
about using MIME, we are really talking about using MIME+XML. The
benefit of the XML envelope approach is that there is only one document
format to contend with, rather than two. There are use cases where this
one document format is ill-suited. But the overwhelming majority of
integrations I've done over the last several years have been all about
exchanging structured information that can fit just fine into an XML
envelope. It would be presumptious for me to generalize too much from my
own experience, but in my own experience SOAP doesn't just hit the 80/20
mark, it hits the 99/1 mark.
I just don't see that MIME should be dictated to those applications that
derive no benefit from it. I certainly wouldn't try to shoehorn every
solution into an XML envelope, though. I think developers should have
the flexibility to use the solution that best suits the problem at hand.
