Re: renaming MTOM

Very much agreed, if we go down that route (which I'm amenable to).


----- Original Message ----- 
From: <noah_mendelsohn@bea.com>
To: "Mark Nottingham" <mark.nottingham@bea.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>; "Xml-Dist-App@W3. Org"
<xml-dist-app@w3.org>
Sent: Monday, July 28, 2003 6:51 AM
Subject: 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 12:14:28 UTC