RE: renaming MTOM

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of 
> jones@research.att.com
> Sent: 17 July 2003 11:23
> To: mark.nottingham@bea.com; xml-dist-app@w3.org
> Subject: 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. 

Except that upon resulution of includes they would end up encoded as
base64 chars at the infoset level. I don't believe that we have a
use-case/requirement to allow the envelope to be broken up in such a
way, do we?

> [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 15:24:16 UTC