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: Sun, 04 Nov 2007 08:57:05 -0800
Message-ID: <472DF9E1.9000401@globalmentor.com>
To: Graham Klyne <GK@ninebynine.org>
CC: Tim Berners-Lee <timbl@w3.org>, www-rdf-comments@w3.org

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
>>>
>>>     
>>
>>   
>
Received on Sunday, 4 November 2007 16:58:17 GMT

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