On 3/19/2000 12:58 AM, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
To summarize:
Most of us are of the opinion that indiscriminate sniffing of objects
is a Bad Idea unless you're of the canine persuasion, and that some
form of tagging is a Good Idea. The question we seem to be hung up on
is whether we should:
a) Use application/xml with Content-Feature tagging. This would
require more work for some MIME dispatchers to implement up front, but
buys us automatic drop-back to generic XML if added support isn't
available. Non-upgraded clients would require (possibly) *one*
intervention to add 'application/xml' to their "how to dispatch THIS
one" tables to point at a generic XML application, but there's no
guarantee that added features would be usable, even if installed, if
their MIME handler doesn't do Content-Feature.
b) Use application/foobar-xml. This apparently requires less work for
some MIME dispatchers to support, at the expense of creating a "rule"
that *-xml is all xml if you don't want to drop back to octet-stream.
In addition, *non-upgraded* clients get to force hand-adding of this
week's foobar-xml to a table of "how to dispatch THIS one" (even if
it's Yet Another 'hand it to our XML application') if they want "better
than octet-stream" handling.
What about:
c) Use application/foobar with a tag that says it's xml, like
Alternate-Type=text/xml.
The reason I think this is better is that a non-upgraded client will handle
a by passing all application/foobar documents to the generic xml handler
rather than the foobar handler, but if the primary type is listed as
application/foobar, a non-upgraded client will handle it correctly if a
foobar handler is installed and set up. It will just fail to pass it off to
a generic xml handler if one isn't installed. This seems like a much less
serious problem to me because there's not much the user can necessarily do
with a application/foobar document in a generic xml handler anyway. It is
much more important to handle the case where the user has a handler for
foobar installed. Also, if we use something like Alternate-Type, it
provides a much more general solution for similar problems in the future,
and the implementation would be very simple. It could be Alternate-Types
with a comma delimited list, as someone else suggested, or there could be
multiple Alterate-Type tags allowed, and you just go through them in order.
You can think of this as being similar to multipart/alternative, but sharing
the same content and just changing the way it's interpreted.
Dan