Ned, since you co-authored MIME RFCs, could you please give us an explicit
criteria of text subtypes?
The problem is that the criteria have changed over time as our understanding of
actual use of markup formats has changed. When MIME was designed we were told
that various formats, notably text/richtext, then text/enriched, and even
text/html, would be capable of being used in such a way that the output would
be readable as-is -- far from beautiful, to be sure, but readable, and that
applications were prepared to do this. Under this theory any material that in
theory could be read a plain text should be registered under text.
But this hasn't happened. In practice the text/richtext, text/enriched, and
text/html applications actually produce is typically an unreadable mess -- in
some cases even by someone fully familiar with the format. (Note that there are
some well behaved applications out there that do generate legible
text/enriched, but they are dwarfed in number by the poorly behaved ones.)
And given these registrations, the practice of putting things under two trees
has carried over to many other types because a feeling has arisen that a
"correctly" registered SGML-derived type needs both a text and application
registration. So we have a bunch of registrations I for one regard as anywhere
from useless to dangerous. (I try to push back on these as media types
reviewer, especially the practice of putting the text-encoding variant under
text and the WAP WBXML binary variant under application, but I'm only
successful in some cases, not all.)
You appear to claim that text subtypes
have to be readable by casual users.
This was always the underlying intent. But what has happened is that many
things have been registered given the promise of readability, and this
has then cascaded into ever sillier registrations.
However, text/css, text/rfc822-headers,
text/vnd.in3d.3dml, text/rtf are already registered.
With the sole exception of text/rfc822-headers, I view all of these
as mistakes.
I do not think
that they are quite readable by casual users. On the other hand, Postscript
programs are application/postscript rather than text/postscript. Is text/css
a mistake?
Text/css is one of the more egregious ones, I think.
In the case of PostScript some people actually argued that readable PostScript
was a possibility. But nobody seriously thought PostScript output drivers would
ever spit out such a thing, so it never got registered under text.
Should XSL become application/xsl-xml rather than text/xsl-xml?
I certainly think it should.
Ned