Re: Wrong MIME type for XML DTDs

On 29.07.01 at 13:37, William F. Hammond <hammond@csc.albany.edu> wrote:

>(Follow-up to www-talk@w3.org)
>
>Content type issues -- apart from the definition of HTML-related
>content types to the extent envisioned in RFC 2854, "The 'text/html'
>Media Type" (which explicitly refers discussion to www-html@w3.org) --
>belong either at IETF or, when about questions of WWW
>interoperability, in www-talk@w3.org.  Issues related to RFC 3023 do
>not belong in www-html.

Left in www-html as that is the proper place to discuss issues related
directly to the HTML Recommendations; e.g. issues with the format, storage,
serving, or presentation of the Recommendation documents themselves. No?


>Is there any actual loss of functionality created by the W3C choice
>of "text/plain" in the cited instance of its HTTP-served DTD for
>"XHTML 1.0 Strict" ?  That is, what is envisioned after a change to
>"application/xml-dtd" that is not, in fact, working now?

Automated processing by Software Agents that know how to deal with
«application/xml-dtd», but which, quite correctly, refuses to attempt to
treat response objects that are explicitly labelled as unstructured, free
form, text as if it had some internal syntax or structure.

We recently hit upon this snag in the W3C HTML Validator when the SGML
parser in use rejected these DTDs due to an incorrect Content-Type.

It is also worth noting that the IETF has repeatedly refused any attempt to
impose pseudo-structure, even by convention, on the «text/plain» media
type. The media type is _strictly_ for human consumption. cf. discussions
on the IETF USEFOR and DRUMS WG mailinglists pertaining to attribution,
quotation, and signature separators.


Tell me. what is your position on MSIE's propensity to treat «text/plain»
as if it were «text/html»? If you make a document named «foo.txt», and
serve it as «text/plain»; would _you_ expect MSIE to treat it as
«text/html»?


>I rather imagine that RFC 3023 idea might be truly useful in EDI
>contexts where HTTP URI's are strictly for end consumption by robots.

The «End User» as such does not ever process a HTTP URI, or the response
object returned. There is always a User Agent involved; even if just
«Telnet».


>>application/xml-dtd does not prevent this.
>
>For most users it is an obstacle.

For most users, the DTD in question is line noise and so the «obstacle» is
irrelevant; it is an obstacle to people who do not want to surmount it,
would never try, and would have no use for it if they did.


>>If the user wants to read documents labeld as applicatoon/xml-dtd, he
>>should configure his browser accordingly. That's how HTTP works; to
>>mislable content as text/plain is
>
>"text/plain" is not a mislabeling just because it is not specific. The
>logic of calling it a mislabeling leads to the absurd idea that a Computer
>Science professor ought to be forbidden from serving didacticly offered
>Perl code as "text/plain".

The question is not whether Perl code is "Plain Text"; the question is
whether your hypotetical Computer Science Professor intends his Perl code
to be _treated_ as «Plain Text» or as «Perl Code». Would you like your User
agent to willy-nilly attempt to execute arbitrary «text/plain» objects on
the off chance that some of them are /really/ supposed to be «Perl Code»?

The DTDs as they are placed, are meant expressly for consumption by
software agents; the «Human Readable» version belongs in a suitably
formatted and marked up Appendix to the relevant Recommendation.


>The existing content types are not primarily for classification. Rather
>they exist for the purpose of enabling agreed types of automatic response
>on remote platforms.

Exactly! Your premise is faulty.


>And we have all been witnesses to the danger of overly enthusiastic use.

Oh? I can only infer, in this context, that you are refering to
«text/html»? In what way is that «overly enthusiastic use»? I'd say it was
the exact opposite. Would you care to elaborate?

Received on Sunday, 29 July 2001 14:23:37 UTC