Re: N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

Garret,

The person to ask for a more definitive view would be Ned Freed (co-author of
RFC2046).  I have read him argue quite compellingly in a public forum that the
adoption of text/html was a mistake, because for non-technical users displaying
the uninterpreted text is just a source of confusion (e.g.
http://osdir.com/ml/ietf.xml-mime/2000-10/msg00049.html).

Also, look to the mailing list which produced RFC 3023
(http://www.ietf.org/rfc/rfc3023.txt) for the discussion of +xml being something
of a special case.  (I think that discussion was also part of the thread I cite
above, but I don't have time to dig deeper right now.)

Also, from RFC 3023 (section 1):
[[
   Similarly, XML will be used as a foundation for other media types,
   including types in every branch of the IETF media types tree.  To
   facilitate the processing of such types, media types based on XML,
   but that are not identified using text/xml or application/xml, SHOULD
   be named using a suffix of '+xml' as described in Section 7.  This
   will allow XML-based tools -- browsers, editors, search engines, and
   other processors -- to work with all XML-based media types.
]]
-- http://www.ietf.org/rfc/rfc3023.txt

I don't think a similar case can be made for either RDF or N3 (for different
reasons).

#g
--

Garret Wilson wrote:
> The following messages seems to be a good overview of some of the
> perceived problems with a text top-level MIME type:
> 
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html
> 
> Of particular interest is the RFC 2046 requirement that all line breaks
> be CRLF, and that CR and LF not appear outside a line break sequence.
> This doesn't worry me so much---after all, "text/xml" seems to ignore
> this requirement (XML allows arbitrary CRs and LSs; see
> <http://www.w3.org/TR/REC-xml/#sec-line-ends>).
> 
> What seems most important to me, however, is that RFC 2046 describes the
> "text" top-level type thus: "Possible subtypes of 'text' thus include
> any word processor format that can be read without resorting to software
> that understands the format" (3.1). This seems to be the defining
> question: can you open and edit the format in a word processor? For N3,
> the answer is yes.
> 
> This would lead to the conclusion of "plain N3" using a MIME type of
> text/rdf+n3, as TBL suggested. I would imagine some specific application
> of N3 to use application/app+rdf+n3, where "app" is the name of the
> application that is uses N3 as its underlying format.
> 
> Garret
> 
> Garret Wilson wrote:
>>
>> When I originally saw that TBL had recommended text/rdf+n3 as the N3
>> MIME type, I was surprised. JSON uses application/json [RFC 4627].
>> XHTML uses application/xhtml+xml [RFC 3236]. text/javascript and
>> text/ecmascript are now marked "obsolete" in favor of
>> application/javascript and application/ecmascript, respectively,
>> noting that, "The use of the 'text' top-level type for this type of
>> content is known to be problematic." [RFC 4329]
>>
>> Looking further on the web, it appears that one of the major concerns
>> is that the character set for "text" content types would default to
>> US_ASCII during HTTP content type negotiation if no "charset"
>> parameter were supplied. However, I read RFC 2046 to say that this
>> only applies to text/plain, and that any future "text" subtypes may
>> specify default character sets other than US_ASCII. But how this is
>> handled in the wild by browsers, I don't know.
>>
>> Whatever the case, there seems to be a trend away from "text" content
>> types (for anything other than text/plain, it seems, which makes me
>> question the usefulness of the entire "text" top-level type, but
>> that's another issue). Are these fears warranted, and should text/* be
>> abandoned in favor of application/*, as Graham suggests? Or will using
>> text/* allow browsers to display the N3 (which seems useful to me) if
>> there is no plugin for N3?
>>
>> Garret
>>
>> Graham Klyne wrote:
>>> Two comments, agreeing text/plain is not ideal...
>>>
>>> 1. My recollection of the IETF discussions around introducing the +xml
>>> convention for MIME content types were focused on applications that
>>> might
>>> recognize the suffix and be able to pass the content to some
>>> application that
>>> could exploit the common framework of XML.  I don't think that
>>> applies here.
>>>
>>> 2. The intent of text/... is that the content can be displayed to
>>> human readers
>>> on text display devices and still be reasonably easy to interpret. 
>>> It has been
>>> commented that, for example, HTML fails on this score, and
>>> application/ would be
>>> a better choice.
>>>
>>> Which considerations suggest to me application/n3 as an appropriate
>>> MIME content
>>> type.
>>>
>>> #g
>>> -- 
>>>
>>> Tim Berners-Lee wrote:
>>>  
>>>> Comment on "RDF Test Cases".
>>>> W3C Recommendation 10 February 2004
>>>>  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>>>
>>>> The Internet media type / MIME type of N-Triples is text/plain and the
>>>> character encoding is 7-bit US-ASCII.
>>>>
>>>> This is a bug, I think.   It  prevents crawlers from absorbing the file
>>>> and indexing it proerly, it will prevent the file from being dispatched
>>>> inside a data browser to a data-handling view, and so on.
>>>>
>>>> I would suggest   text/rdf+n3   if the assumption is correct that
>>>> NTriples is a subset of N3.
>>>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>>>> possibility would be
>>>> text/rdf=n3; level=nt
>>>> introducing a level parameter to explain what level of N3 was being
>>>> used.
>>>>
>>>> Tim BL
>>>>
>>>>     
>>>
>>>   
>>
> 

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Sunday, 4 November 2007 22:32:46 UTC