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

Re: renaming MTOM

From: John J. Barton <John_Barton@hpl.hp.com>
Date: Wed, 16 Jul 2003 18:39:17 -0700
Message-Id: <>
To: Mark Nottingham <mark.nottingham@bea.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

Message Packaging Optimization Mechanism would be my suggestion.
The layer is not Transfer as in  htTp, nor serialization as you note below.

At 05:50 PM 7/16/2003 -0700, Mark Nottingham wrote:

>On today's concall, there was some concern expressed about the name chosen 
>for our current work, especially regarding "Optimization." As a result, I 
>took an AI to kick off discussion of other possible names, and their 
>respective merits.
>* Option 1: Message Transfer Optimization Mechanism (no change)
>"Optimization" emphasizes the purpose for using the mechanism; i.e., we're 
>doing this so that people can improve performance, efficiency or other 
>characteristics of message transfer.
>The objection to this name was that people may use the mechanism we 
>describe without intending to optimize the message transfer (I'm not sure 
>of the exact cases here; could someone who believes this expand upon this 
>* Option 2: Use "Encoding" (e.g., "Alternate XML Encoding")
>I view the problems addressed by PASWA and MTOM as pure encoding problems, 
>since their representations are isomorphic to vanilla XML 1.0. In this 
>manner, they are very similar to MIME (Content-Transfer-Encoding) and HTTP 
>(Content-Encoding) mechanisms.
>The problem here is that "Encoding" has other meanings for XML people 
>(character encoding) and SOAP people (SOAP Section Five Encoding), and 
>therefore may be confusing.
>* Option 3: Use "Serialization" (e.g., "Alternate XML Serialization")
>Another suggestion was to use "Serialization," because we're defining an 
>alternate serialization of the message Infoset. This approach has many of 
>the advantages of "Encoding"; it emphasizes the fact that it's just a 
>different representation of the Infoset.
>I'm not aware of any objections to the term 'Serialization."
>* Option 4: Choose a completely unrelated name.
>"SOAP" doesn't convey any information about what it is or attempts to do 
>in its name (or, at least, it doesn't any more). We could take the same 
>approach for this work.
>In making this decision, we should probably keep the following in mind:
>* We may be producing more than one specification, so the name doesn't 
>need to address all of the functionality we're talking about (and we may 
>need to wait until we determine what the deliverables will be; we have a 
>slot scheduled for this during the F2F).
>* The name chosen may also be affected by how our solution is layered into 
>SOAP; e.g., if it's a content-coding in HTTP, "Encoding" makes more sense, 
>whereas if it were a new format with a separate media type, 
>"Serialization" might.
>* We should also consider whether the mechanism we define might be reused 
>by other XML applications; if it's likely, we may want to de-emphasize the 
>messaging aspect.

John J. Barton          email:  John_Barton@hpl.hp.com
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100
Received on Wednesday, 16 July 2003 21:39:23 UTC

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