Re: renaming MTOM

In this spirit, how about:

        Base64Binary SOAP Optimization Feature

or if you prefer

        Base64Binary Serialization Optimization Feature

I think we should only go for "Type Aware" if we decide to generalize 
beyond Base64, leaving the more general name free for the future (it's so 
catchy, I'd hate to use it prematurely.)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Mark Nottingham" <mark.nottingham@bea.com>
Sent by: xml-dist-app-request@w3.org
07/21/2003 04:02 PM

 
        To:     "Jacek Kopecky" <jacek@systinet.com>
        cc:     "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: renaming MTOM



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.
> >
> >
>

Received on Monday, 28 July 2003 09:57:09 UTC