Ned Freed re Larry:
| > I think there is no justification for "text/xml-dtd" in addition
| > to "application/xml-dtd", because there is no utility at all
| > for an unaware recipient to attempt to display a dtd to a
| > user as if it were text, which is the reason for having a
| > "text/" top level type in addition to "application/".
|
| I agree. And I'm sorry, but the argument that "people expect DTDs to be
| displayed as text" just doesn't wash -- technical experts (who are capable
| of configuring their agents to do anything they want) may expect this, but
| the average user doesn't know diddly about XML or DTD and doesn't want a
| bunch of incomprehensible stuff displayed on his or her screen.
Correct. But in some contexts, the entity serving the resource wants
it to be displayed as text. So I can see a case for having both
text and application, as I believe we do for SGML, of which XML is
only a profile.
I think the definition of a text subtype for SGML was an error, and as such
I don't want to repeat it with XML.
As for serving out something with the intent of displaying it as text, I don't
think it is the server's business to tell the client how to display something.
The MIME media type model is to label things as to what they are, not how they
are to be handled. If a server wants to give an indication as to how something
is to be handled it should use another mechanism like content-disposition.
Ned