Request for review of Turtle (an RDF serialization) media
eric at w3.org
Tue Dec 18 18:48:22 CET 2007
* Julian Reschke <julian.reschke at gmx.de> [2007-12-18 15:24+0100]
> Eric Prud'hommeaux wrote:
>> W3C is about to publish a Team Submission for the RDF serialization
>> Turtle. A mockup of the document to be published is at
>> Because the document will include the text of the media type
>> registration, I am vetting this registration with ietf-types before
>> publishing the document. Some discussion about the claim to force
>> utf-8 encoding (and not require that in a charset parameter) can be
>> seen at http://lists.w3.org/Archives/Public/www-archive/2007Dec/
>> (Subject: Media types for RDF languages N3 and Turtle)
>> I got moderator-actioned for having too many folks in the Cc so
>> I'm Bcc'ing them all in this request for review:
> 1) If text/* proves to be problematic, why not use application/*?
Turtle is a form of RDF that was designed to be specifically
human-readable. It is unlikely that RDF will ever have a more texty
2046 §4.1. Text Media Type ¶2:
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".
Yes, text/* is problematic, but if we figure out what it can and can't
do, they the institutional knowldege will hopefully transfer to the
next poor sucker who tries to register a non-ascii language in text/ .
Ceretainly, I'm certainly willing to give up and fall back to
application/ , but I worry that no modern languages are appropriate
for text/ and that we are hostage to a legacy exactly counter to the
intent of the tree.
> 2) Also, keep in mind that while RFC2046 may be interpreted not to mandate
> the ASCII default for text types other than text/plain, there's also
> RFC2616 saying...:
> The "charset" parameter is used with some media types to define the
> character set (section 3.4) of the data. When no explicit charset
> parameter is provided by the sender, media subtypes of the "text"
> type are defined to have a default charset value of "ISO-8859-1" when
> received via HTTP. Data in character sets other than "ISO-8859-1" or
> its subsets MUST be labeled with an appropriate charset value. See
> section 3.4.1 for compatibility problems. --
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3#sec3.4.1 explains the
motivation of this rather painful rule; current practice of some old
and broken HTTP/1.0 implementations.)
This asserts extra constraints on participants in HTTP transactions
above and beyond those of othter agents exchanging MIME e.g. MTAs and
MUAs. If the media type for turtle was as I wrote, 2616 would say that
web servers would still have to supply the charset=UTF-8 parameter.
When that deference to legacy gets obsolesced, the media type will not
need updating. This reduces our choices to comparing the relative
1. failure to present a fairly intelligible form to the consumer.
2. must include charset in HTTP for the foreseeable future.
> See also the related HTTPbis issue:
> BR, Julian
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
(eric at w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20071218/d1007a46/attachment.bin
More information about the Ietf-types