Michael Brennan wrote:
>
>...
>
> 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.
In practice you are almost always transmitting SOAP messages over a MIME
transport like HTTP or SMTP anyhow.
> 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.
I am strongly disinclined to distinguish between "web services" and "web
sites" and "B2B" and "B2C" until and unless it is *absolutely necessary*
(and demonstrated so!). Obviously we do need new standards for web
services (service description languages come to mind) but I think it is
a bad idea to have branches in the architecture for trivial things.
You talk about sending "structured information, not documents" around
the Web. But to me, a purchase order is a structured document -- both
structured information and a document. This has practical implications:
1. The vast majority of existing, XML-based ebusiness standards still
use DTDs (e.g. FIX)
2. I may want to add an xml-stylesheet processing instruction to a
purchase order to allow optional rendition (even in an e-business
scenario)
3. If I generate an XML text stream from an XSLT running in a web
service, do I really want to be forced to reparse that so that I can
insert it into the SOAP stream? Seems a waste of effort to me!
4. If I use XInclude for such a document should that be interpreted by
the SOAP processor or some other processor that runs after. (see also
the discussion with Uche!)
>...
> 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.
I didn't say it was a technical issue with DIME's approach. I said it
was a strike against DIME and I still feel that to be the case.
>...
> 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 application should not deal with any document formats. The
application should get a list of headers and optionally a body object.
If the application is worrying about the syntax of messages at all then
there is something wrong the framework it is built upon.
As far as the framework goes: the chances are quite high that it is
parsing a MIME message *anyhow* because typically the "transport" is
HTTP or SMTP.
>...
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'd suggest that MIME+XML hits the 100/0 mark. ;)
Paul Prescod
