It isn't clear to me whether your opposition is to the creation of new
top-level media types period, or just to xml/.
I'm opposed to creating more top-level media types than are necessary,
or to adding more parameters and other doodads than are necessary,
where I define 'necessary' as 'having a compelling application TODAY'.
So far, I've seen some good arguments for text/xml, application/xml,
a few calendaring applications and (possibly, if the issues about
subsets and compositions are elaborated), text/xhtml.
If registration activity is any indication, there are a lot more XML-derived
things out there that need their own media types than this.
However, I agree that not everything does, so our disagreement, such as it is,
seems to be more a matter of degree than anything else.
But I don't see any reason for creating new media types otherwise,
until they're needed. For the most part, applications can use
text/xml, application/xml, or even application/octet-stream, since
the MIME type is irrelevant.
Um, well, actually, in many cases the MIME type is very relevant and is used to
get the data delivered to the right place. While it may be nice to imagine a
world where there's a separate XML-level dispatch process, such a process
doesn't exist in any product I'm aware of and I don't see any moves underway to
I don't believe that "xml" fits into the guidelines for new
top level types, which seem to rest, not on the argument about
"default processing" but rather "device/gateway filtering".
I've been thinking about this a lot of late, and I'm afraid that while I was
largely neutral about a new top-level type before, I have to agree with Larry
on this point.
In particular, XML seems to me to cut across existing top-level media types --
an XML object can be a document or some other form of application data, a
model, an image, a means of storing audio data, or even some sort of message or
Mind you, I'm not saying that XML objects will eventually end up being
registered under every existing top-level type -- registration under multipart
is certainly unlikely at a minimum -- but registration under several top level
types seems certain.
At least notionally, the distinction was between text/ image/
audio/ video/ and (now) model/, with "application/" being the
catch-all for everything else. I think "xml" is, for the
most part, "application/".
For the most part, perhaps, but not always. I see a bright future for XML
under model at a minimum, and likely under image and audio as well.
As for XML appearing as a distinguished registration tree "xml.", the current
purpose of differing registration trees is for when someone other than IANA
wants to do the registration or when the rules for registration are
significantly different from existing trees.
But neither of these seem to apply here. W2C is the logical candidate for an
alternate registration authority, but they don't seem interested in doing XML
registration (according to previous messages on this list at least). And I see
nothing about XML that calls for significantly different rules.
And remember that the IETF isn't likely to register the XML types it defines
in an "xml." tree. They'll prefer the unfaceted IETF tree. So the separate
tree would almost certainly fail to capture all XML, making it useless for
spotting all XML-based objects.