[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -1 on MIME-in-XML (was Re: PaceSimpleContentType)
Paul Hoffman / IMC <phoffman@xxxxxxx> writes:
> Just to be clear: are you against using any MIME content-typing in
> XML, or using MIME multi-parts in XML? I could certainly agree with
> the latter, but the former seems a useful way to say "this blob has
> the following format" in a way that stays with the blob.
Definitely against multipart.
Regarding Internet Media Types, there are two issues:
1) for content not in base64, a media type does not automatically
denote an Atom-specific profile of an Internet Media Type that
will be represented typically as a partial document (aka fragment)
using XML characters (not octets).
For each non-base64 media type Atom might support, a profile
(formal or informal) must be assumed. For the profiles we intend
to initially provide interop for, XHTML and HTML, we need to to
specify how to represent those document fragments. For example,
is <body> allowed? <html>? document types? what versions?
text/plain doesn't work as expected[1-4], its profile would either
not satisfy anyone or be equivalent (anyway) to "XHTML with only
character data markup".
A large number XML fragment profiles won't have unique media
types, so the generic application/xml is redundant.
2) for content in base64, is a media type identifier alone
sufficient? What about the rest of the content-type (parameters),
transfer-encoding (besides base64), and other content headers
commonly associated with HTTP or MIME content transfer?
For (1), an Internet Media Type is questionably applicable.
For (2), if we come to consensus that base64 and an Internet Media
Type identifier alone is sufficient, it may be an 80/20 solution where
we will have to clarify its use over time.
So, I'm more against poorly identified blobs than I am against
advisory media types for those blobs.
I would prefer naked HTTP for the Atom API and real MIME for Atom
archives. Blobs are a second choice.
-- Ken
[1] http://imc.org/atom-syntax/mail-archive/msg04292.html
[2] http://imc.org/atom-syntax/mail-archive/msg04350.html
[3] http://imc.org/atom-syntax/mail-archive/msg04363.html
[4] http://imc.org/atom-syntax/mail-archive/msg04364.html