renaming MTOM

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.

Received on Wednesday, 16 July 2003 20:50:56 UTC