Re: 0.2, do we *really* need multipart/alternative?

[Ken MacLeod <ken@xxxxxxxxxxxxxxxx>]

Tim Bray <tbray@xxxxxxxxxxxxxx> writes:

> There's nothing like writing a schema to make you read a spec
> carefully. I really wonder if multipart/alternative content really
> falls into the category of, to quote Mark's entry from today, "the
> simplest thing that could possibly work"
> (http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html).
> 
> I guess I wasn't looking when this was hashed out on the Wiki.  But
> from here, it looks like the sole baroque blemish on what is
> otherwise an elegantly-minimal and still very flexible design.

Do we *really* need multipart/alternative?  Short answer is "possibly
not, but it's the best solution we'd come to so far".

The background goes something like this:

 * an Atom use-case is to support media blogs now becoming common.

 * there was discussion about allowing multiple <content> elements,
   but without providing a processing model.  Most were thinking of it
   logically as a multipart/alternative, where the use-case is truly
   more like multipart/related.

 * MIME provides a processing model.  If we allow only one <content>,
   which has a media-type anyway, we can have the media-type be
   multipart/related or multipart/alternative and use a well-defined
   and tested processing model.

 * multipart/alternative seems to have caught on as the way to have an
   example of both escaped and inline content of the same media-type,
   or possibly as a technique to allow consumers to choose whether
   they want escaped or inline content.  The latter seems like "too
   many options, not supported by all publishers, so consumers have to
   support both anyway, so why start?" sort of option.

There are still a few issues with <content>:

 * A consistent model must be developed, with as few interrelated
   processing options as possible[1].  Given that <content> emulates
   HTTP/MIME resource entities, it thus seems natural that after
   decoding the mode, one has the XML characters or octets of the
   resource entity (or an XML tree, for mode="XML").

 * A complete *ML resource entity includes a DOCTYPE or an XML
   declaration, which means it must be escaped or base64.

 * The resource entity encoding for MIME multipart/* is already
   defined.  Maybe we can key off of mode="xml" to introduce the XML
   encoding used in the wiki examples.  See
   MultipleContentDiscussion[2].

 * The 'src' attribute for include-by-reference isn't well understood.

 * base64 for use in the editing and archiving APIs is bulky.

One completely different alternative is to have an Atom entry have
only one plain text or X/HTML markup content, where the Atom <entry>
acts as the "root" resource entity of a surrounding real MIME
multipart/related resource entity.

  -- Ken

[1] An example of interrelated processing options includes, "if type
is FOO then mode can be assumed to be BAR; but if mode is TANGO then
type can be assumed to be BRAVO."

[2] http://intertwingly.net/wiki/pie/MultipleContentDiscussion