Re: renaming MTOM

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 
>reasoning?).
>
>* 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
http://www.hpl.hp.com/personal/John_Barton/index.htm
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