Anybody else working on systems that translate MIME into a compound document
format? I'm in the process of adding support for MIME in BBN/Slate and am a bit
puzzled about how to handle Multipart/Alternative. I certainly don't want to
throw any information away, and I don't want to show multiple alternatives.
However, I'm producing a single document non-interactively and therefore
can't query the user about which alternative they are interested in.
Alternative parts that themselves are multipart obviously introduce further
complexities as the RFC acknowledges - in that case it suggests that you can
back off and show multiple alternatives (at least when the multipart contains
unrecognized subparts).
The case that seems typical would be a situation where I have a text
alternative and an unrecognized application alternative. I want to keep the
application data around, since the user may be able to export it to the
application. But I want to show the text alternative, since that's the one
that's directly readable. I could import the application data as an
enclosure (within Slate, that shows up as a small labeled box) and could make
the argument that I'm not actually "showing" multiple versions of the same
data. However, then I've lost the information that this is actually an
"alternative" view (I would have to hope that that was clear from the context -
ugh).
How does Andrew address this problem?
Interestingly enough, ODA (at least in the draft version), only allowed textual
alternative representations.
One could argue that an application that produces alternative representations
where it is difficult to decide which to use (without the user actually
seeing what the results are) is being unfriendly and getting what it deserves.
Terry Crowley