On Saturday, June 18, 2005, at 06:28 PM, David Powell wrote:
Atom 0.3 multiparts forced a dubious and complex processing model on
everyone wanting to process Atom documents. This problem was solved by
their removal in the 03 to 07 drafts.
The prohibition of composite types in the 08 draft (made many months
later) is something quite different.
I haven't combed through the archives for messages to support this, but
had you asked me, I would have thought that we had explicitly decided
to disallow composite types, not just to get rid of 0.3's multipart
stuff.
Composite types don't impose any
change in the processing model of user-agents, they are just blobs
that get passed to a MIME processor; there is no justification for
restricting Atom payloads to a subset of the MIME type space.
Not all user-agents have a "MIME processor". Given the potential
complexity and messiness of composite types, I'm opposed to leaving the
door open for them, since they won't, I think, be needed by a
significant proportion of Atom users. This brings back bad memories of
some really ugly data I saw coming out of Cyber Dog when I was working
on Claris Emailer (Japanese)--a very convoluted and in fact buggy mess
of multipart/alternative and multipart/mixed with lots of duplicated
data which forced us to handle composite types incorrectly to avoid
losing data. Yes, that's just one anecdote. But it's an example of
the kinds of ugliness that can spill over from one bad implementation
and mess things up for everybody. Unless there's a use case that meets
the so-called 80/20 threshold, I'd be in favor of requiring publishers
to keep things a little simpler within Atom feeds. If somebody really
needs composite types, they can use an extension, and user-agent
developers can decide whether to support it.
