Re: renaming MTOM

SOAP Message Attachment Reification Technology. SMART for short.

Marc.


On Monday, Jul 21, 2003, at 16:02 US/Eastern, Mark Nottingham wrote:

>
> One other thought -
>
> The optimisation we're contemplating is fairly specific - we want to
> re-encode portions of the message based on their data types. Unless we
> plan to allow all serialization-based optimisations (e.g., GZIP) to be
> encompassed by the abstract feature, I'd suggest we name appropriately,
> e.g., "Type-Aware Serialisation Optimisation", or "Type-Aware Chunked
> Optimisation" if we wanted to be more implementation-specific 
> (although I
> confess the latter is more appealing for its acronym than its
> appropriateness.)
>
> Cheers,
>
>
> ----- Original Message -----
> From: "Jacek Kopecky" <jacek@systinet.com>
> To: "Mark Nottingham" <mark.nottingham@bea.com>
> Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
> Sent: Friday, July 18, 2003 8:42 AM
> Subject: Re: renaming MTOM
>
>
>>
>> Mark, others,
>>
>> I think that Message Serialization Optimization Mechanism (MSOM) or
>> Message Packaging Optimization Mechanism (MPOM) is a good name for the
>> package that contains the abstract optimization feature and its 
>> concrete
>> implementation in SOAP HTTP binding. So if the other stuff that we're
>> potentially going to add will be added in different documents, the 
>> name
>> is OK.
>>
>> If we want to add MIME typing and carrying web resource 
>> representations
>> sections into the document, I'd suggest a different name and I 
>> wouldn't
>> be afraid of using the name "attachment" either. I think "SOAP with
>> Attachments" is a good name, but alas, it's taken. 8-)
>>
>> Let's see what PASWA does:
>>
>>      1. it supports the transmission of web resource representations 
>> in
>>         SOAP messages - this is one major thing people want to do
>>      2. it supports the encapsulation of binary data (with MIME 
>> content
>>         type) in XML - necessary for the first thing and also a major
>>         thing people want
>>      3. it optimizes the transfer of such XML envelopes - by itself 
>> not
>>         something people are crying for, but it is necessary for the
>>         previous thing
>>
>> The first thing means attachments, the second thing means generic 
>> data,
>> so a synthesized name would be something like: "Binary data and
>> Attachments in SOAP".
>>
>> Enjoy the discussions, I'm going on vacation now. 8-)
>>
>>                    Jacek Kopecky
>>
>>                    Senior Architect
>>                    Systinet Corporation
>>                    http://www.systinet.com/
>>
>>
>>
>>
>>
>>
>> On Thu, 2003-07-17 at 02:50, 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.
>>>
>>>
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Monday, 21 July 2003 17:24:20 UTC