W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2003

Re: Options for flagging MTOM processing (pros and cons)

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 27 Aug 2003 15:13:35 -0700
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: noah_mendelsohn@us.ibm.com
Message-Id: <B3D9E86B-D8DB-11D7-B391-00039396E15A@bea.com>

On Wednesday, AugAn alternate media type might be "application/mtom+xml;
>> content="application/soap+xml"
> You are more expert in these things than I, but I think we should at 
> least
> consider application/soap+mtom+xml or application/soapmtom+xml.  I'd 
> like
> to better understand the tradeoffs relative to using content= as you
> suggest above.  Thanks!

I've become dissatisfied with the overhead required to register media 
types, especially for XML-based formats (see [1] for more details). One 
solution that I've heard suggested is to use "application/xml" instead 
of the RFC3023 "+xml" convention, but to add a parameter that indicates 
the specific content format; i.e., either a schema URI, the root 
namespace URI, or a similar identifier. This would make SOAP's media 
type something like
   application/xml; ns="http://www.w3.org/2003/05/soap-envelope"
and MTOM might turn out like
   application/xml; ns="http://www.w3.org/2004/01/mtom-soap-envelope"
This would, of course, require modification of the XML media type 
registration (RFC3023).

Registering MTOM as a media type with a similar mechanism might make 
sense if we believed the MTOM include mechanism would be useful for 
other, non-SOAP applications of XML, which could then reuse the media 
type with different content parameters (and hence, my example really 
should have been ''application/mtom+xml; 
content="http://www.w3.org/2003/05/soap-envelope"' ).

This suggestion was mostly me thinking out loud on these issues (or 
maybe just leakage from those thoughts); if we choose to give MTOM its 
own media type, it's probably best to register a distinct one as you 
suggest, and wait for the greater problem to be fixed in due time.


1. http://www.mnot.net/blog/archives/000145.html
Received on Wednesday, 27 August 2003 18:14:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC