Re: renaming MTOM

I think I would prefer a term that uses "serialization", which is
really what we're defining.  The resulting MIME-multipart packaging
need not represent any particular optimization at all.  The parts
may even contain XML fragments which would be identical if they
were coded "in-line" in the SOAP envelope.  [In some use cases,
it is a convenience to build messages in this way if the headers
express properties of a dynamically constructed body.]

"Serialization" doesn't quite capture the potential for lazy
expansion of Include, but this is more of a run-time optimization
than a wire-format transfer optimization.

Mark Jones
AT&T


	From xml-dist-app-request@w3.org Wed Jul 16 20:51 EDT 2003
	Delivered-To: jones@research.att.com
	Resent-Date: Wed, 16 Jul 2003 20:51:17 -0400 (EDT)
	Resent-Message-Id: <200307170051.h6H0pHsF010243@frink.w3.org>
	Date: Wed, 16 Jul 2003 17:50:56 -0700
	Mime-Version: 1.0 (Apple Message framework v552)
	From: Mark Nottingham <mark.nottingham@bea.com>
	To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
	Content-Transfer-Encoding: 7bit
	Subject: renaming MTOM
	X-Archived-At: http://www.w3.org/mid/B99F1B5E-B7F0-11D7-B152-00039396E15A@bea.com
	Resent-From: xml-dist-app@w3.org
	X-Mailing-List: <xml-dist-app@w3.org> archive/latest/7878
	X-Loop: xml-dist-app@w3.org
	Resent-Sender: xml-dist-app-request@w3.org
	List-Id: <xml-dist-app.w3.org>
	List-Help: <http://www.w3.org/Mail/>
	List-Unsubscribe: <mailto:xml-dist-app-request@w3.org?subject=unsubscribe>
	X-Spam-Status: No, hits=-2.6 required=4.0
		tests=BAYES_20,USER_AGENT_APPLEMAIL,X_LOOP,X_MAILING_LIST
		version=2.55
	X-Spam-Level: 
	X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)


	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 Thursday, 17 July 2003 14:23:03 UTC