I have been reading the XML tagging discussion, here is a
short summary of my understanding of the problem:
The discussion relates to how a specialized application,
such as foobar, should label its MIME content-type, when
foobar uses XML as a basis for its encoding format.
Requirements:
(1) The normal MIME format should be used, with a content-type
such as application/foobar.
(2) There is a need to indicate in the header, that foobar
actually is based on XML.
(3) Body parts in the application/foobar format should be handled
by a special foobar application handler. If, however, no
foobar application handler is available, the applications
should alternatively be handled by a generalized xml
processor.
Possible solutions:
(a) Use content-type such as application/foobar-xml, where
"-xml" tells the mailer, that if no special "foobar-xml"
handler is available, then a general-purpose application/xml
handler should be used.
(b) Use content-type such as application/foobar, and add a
parameter to this content-type such as
Alternative-Content-Type: application/xml.
(c) A variant of (b), where the added header is named
Super-Content-Type: application/xml.
Pros and cons of the different solutions:
Solution Pros Cons
(a) application/ No change to Not neat to require
foobar-xml MIME specs. mailer to parse the
subtype string.
(b) Alternative- Easy to implement, Some mailers which
Content-Type parameter neat. do not know of this
parameter may be
confused.
(c) Super- Gives MIME new Should be carefully
Content-Type parameter powerful capability thought-through
with object-oriented to fit other possible
structure of content- uses, what about
types. several levels of
superclassing for example?
My conclusion is that (b) seems to be the best alternative, unless
we want to really think through an object-oriented structuring of
subtypes.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/