W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2007

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

From: Garret Wilson <garret@globalmentor.com>
Date: Sat, 03 Nov 2007 10:49:23 -0700
Message-ID: <472CB4A3.6000303@globalmentor.com>
To: Graham Klyne <GK@ninebynine.org>
CC: Tim Berners-Lee <timbl@w3.org>, www-rdf-comments@w3.org

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
>>
>>     
>
>   
Received on Saturday, 3 November 2007 17:50:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:34 GMT