- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 27 Aug 2003 15:13:35 -0700
- To: noah_mendelsohn@us.ibm.com
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
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. Cheers, 1. http://www.mnot.net/blog/archives/000145.html
Received on Wednesday, 27 August 2003 18:14:44 UTC