Having read the disussion so far, I believe that we have agreed on
a few things and would like to know if somebody disgarees.
1. Registration of media subtypes is easy.
2. Dispatch based on parameters are not widely supported.
3. Fallback to general-purpose XML applications is not useful.
4. Document-like XML documents can be handled by general-purpose
XML viewers
If these are agreed on, we can eliminate some options and concentrate on
the rest.
If you disagree with these four points, please speak up now.
Cheers,
Makoto
----------------------------------------------------------
1. Registration of media subtypes is easy.
"Registrations now routinely take only a few days if they don't contain
egregious errors." (Ned)
"Registrations containing errors take longer, of course. But feedback is quick,
typically taking only a day or two, so the burden is on the person doing the
registration to turn the thing around in a timely way." (Ned)
"The registration process is the same (i.e. fast) in *any* tree that
currently exists. The slowness associated with the IETF tree has to do with
RFC review, which is an entirely separate process from type registration." (Ned)
"The standards say that RFC documentation is only required for registration
in the IETF tree, and in practice none of the many registered XML-based types
have been backed up with RFCs." (Ned)
"Moreover, relatively few types belong in the IETF tree." (Ned)
2. Dispatch based on parameters are not widely supported.
"The lack of ability to dispatch on parameters in most applications that
support MIME. Not only do applications lack this ability, there are also
quite a few contexts where MIME labelling is used that don't support
parameters, period." (Ned)
"Many current implementations of content dispatch don't allow dispatch
based on media type parameters, in any case." (Larry)
3. Fallback to general-purpose XML applications is not useful.
"What's the XML parser going to do with this block of data? Display it? Not
terribly valuable. Get some namespace information from the inside and then
dispatch based on the namespace? Possibly valuable, but this begs the
question of why wasn't that information out in the MIME headers." (Paul)
"what experience has shown is that fallback
strategies of *any* sort tend to be overrated. In almost every case something
has messed it up. Either we got the granularity wrong (and I see a very good
chance of this happening here given the emergence of alternative forms of XML),
or it didn't prove to offer useful functionality, or it simply didn't deploy in
the manner in which we envisioned. About the only success story we have,
actually, are the image/audio/video top-level types, and while these have
worked out tolerably well, their actual value to end users isn't that great."
(Ned)
"Not even possible, in some cases. XML is being used for all sorts of
things from serialising Java Beans to Web server configuration files to
interprocess communication - a lot of these uses are not especially
"displayable". In some cases, the fact that they are written in XML is
the least important thing about them. These are likely to need
specialised registrations, too. Further, if the specification for any
such case is not controlled by a single vendor, then registration in the
vendor tree does not seem appropriate. This would be the case for
situations ranging from a small vendor group (such as the Flashpix
group) through groups such as W3C to bodies such as ISO, ITU, IEE and so
on." (Chris)
4. Document-like XML documents can be handled by general-purpose XML viewers
"1.a the generic something displays the XML to a human using a
stylesheet, possibly with help from other logic for embedded chunks
from different namespaces." (Tim)
"Then there is a second class of uses which are essentially textual,
where the XML markup is being used to structure headings, footnotes,
chapters and suchlike document-like things. These things do indeed
benefit, if not recognised, from being "displayed" and may even contain
an internal link to a stylesheet which can be used to display them. I
think that dispatching this 'marked up text' class of uses to a single
parser/viewer, such as a browser, make sense (not in all cases of
course, and editing should be distinguished from viewing, but full
mailcap files can do that) and thus, a MIME labelling of text/xml would
make sense." (Chris)