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, 21 July 2003 16:03:16 UTC