Re: Introduction of media types for XML DTDs

[MURATA Makoto <murata@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Ned Freed wrote:
> 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.

Ned, since you co-authored MIME RFCs, could you please give us an explicit  
criteria of text subtypes?   You appear to claim that text subtypes 
have to be readable by casual users.  However, text/css, text/rfc822-headers,
text/vnd.in3d.3dml, text/rtf are already registered.  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?  Should XSL become application/xsl-xml rather than text/xsl-xml?

Cheers,

Makoto
-------------------------------------------------------------------------

RFC 2046: defitition of the top-level media type "text"

> 4.1.  Text Media Type
> 
>    The "text" media type is intended for sending material which is
>    principally textual in form.  A "charset" parameter may be used to
>    indicate the character set of the body text for "text" subtypes,
>    notably including the subtype "text/plain", which is a generic
>    subtype for plain text.  Plain text does not provide for or allow
>    formatting commands, font attribute specifications, processing
>    instructions, interpretation directives, or content markup.  Plain
>    text is seen simply as a linear sequence of characters, possibly
>    interrupted by line breaks or page breaks.  Plain text may allow the
>    stacking of several characters in the same position in the text.
>    Plain text in scripts like Arabic and Hebrew may also include
>    facilitites that allow the arbitrary mixing of text segments with
>    opposite writing directions.
> 
>    Beyond plain text, there are many formats for representing what might
>    be known as "rich text".  An interesting characteristic of many such
>    representations is that they are to some extent readable even without
>    the software that interprets them.  It is useful, then, to
>    distinguish them, at the highest level, from such unreadable data as
>    images, audio, or text represented in an unreadable form. In the
>    absence of appropriate interpretation software, it is reasonable to
>    show subtypes of "text" to the user, while it is not reasonable to do
>    so with most nontextual data. Such formatted textual data should be
>    represented using subtypes of "text".


Here is the list of currently registered subtypes of text.

> text            plain                            [RFC1521,Borenstein]
>                 richtext                         [RFC1521,Borenstein]
>                 enriched                                    [RFC1896]
>                 tab-separated-values                   [Paul Lindner]
>                 html                                        [RFC1866]
>                 sgml                                        [RFC1874]
>                 vnd.latex-z                                   [Lubos]
>                 vnd.fmi.flexstor                             [Hurtta]
> 		uri-list				     [Daniel]
> 		vnd.abc					      [Allen]
> 		rfc822-headers                              [RFC1892]
> 		vnd.in3d.3dml				     [Powers]
> 		prs.lines.tag				      [Lines]
> 		vnd.in3d.spot                                [Powers]
>                 css                                         [RFC2318]
>                 xml                                         [RFC2376]
> 		rtf					    [Lindner]
>                 directory                                   [RFC2425]
>                 calendar                                    [RFC2445]
> 		vnd.wap.wml				      [Stark]
> 		vnd.wap.wmlscript			      [Stark]
> 		vnd.motorola.reflex          		     [Patton]