RE: text/xml for SOAP is incorrect

Dan wrote,

>As XML becomes more common, it is quite likely to have multiple XML parsers
on
>your machine. The issue for the MIME transport engine, then, is to which
parser the
>MIME object should be dispatched. Clearly, a DocBook or RFC 2629-based XML
>document should be handled differently than SOAP. Now yes, this is exactly
what
>DTDs are for, but the argument is that also putting the information in the
MIME type
>makes dispatch much simpler, especially for existing mail, file, and HTTP
engines
>(not to mention emerging BEEP ones). These arguments are well-covered in
>Appendix A of RFC 3023.

The pre-SOAP version of ebXML's message service followed RFC 3023 and
created a MIME media type of application/eb+xml. This MIME media type was
chosen so that generic message brokers could  dispatch incoming messages to
the proper handler by a simple mapping each media type to a specific handler
(as described by Dan).

When ebXML's Message Service converged with SOAP the application/eb+xml
media type was replaced with text/xml, per SOAP 1.1. This posed a problem
for generic message brokers because they could no longer identify the
correct message handler from the MIME Content-type header.

There are two general approaches to solve this problem for generic message
brokers:

1. provide them with intimate knowledge of every message tagged with
text/xml so they can examine XML documents to decide which message handler
should receive and process the message/document.

2. Use a MIME header to provide the information needed by generic message
brokers to dispatch processing to the proper message handler without having
to process/scutinize the message body.

ebXML chose to follow 2. The SOAPAction header is being used to provide the
"clue" needed by generic message brokers to identify the proper message
handler.

I'm currently working on a project  in the Energy industry where ebXML's
Message Service will be used for secure transport functions. This is a
*very* high volume transaction processing site that receives different types
of XML, EDI and multipart/form-data messages. The generic message broker
used by this site cannot be bogged down by having to scrutinize each message
body to determine proper processing. It's imperative to make dispatching
information available at the MIME header level so that generic message
brokers can dispatch message processing quickly and efficiently.

If the XMLP workgroup were to "loosen" the restriction on the MIME media
type (text/xml) by allowing RFC 3023 types, I believe this would eliminate
the need for the SOAPAction header, as it pertains to ebXML.

Dick Brooks
co-author ebXML Message Service 1.0

Received on Tuesday, 18 September 2001 10:33:10 UTC