W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2011

Re: ISSUE-102 (@prefix limit): Should @prefix be limited to HTML, HEAD and BODY? [LC Comment - RDFa Core 1.1]

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 18 Aug 2011 09:53:39 -0400
Message-ID: <4E4D1963.8000902@digitalbazaar.com>
To: public-rdfa-wg@w3.org
On 08/11/11 09:13, Tracker wrote:
> ISSUE-102 (@prefix limit): Should @prefix be limited to HTML, HEAD
> and BODY? [LC Comment - RDFa Core 1.1]

I checked with a number of browser folks yesterday about this issue and
they confirmed that what Ivan is seeing with character set declarations
is what happens. They also explained that the problem has no clear
solution in sight. The entire chat log about the topic can be found here:


Not only should we probably not limit @prefix to HTML/HEAD, having a
decent sized @prefix on HTML/HEAD will cause character encoding sniffing
to fail. This is particularly bad for documents on disk. Everything is
fine as long as a character encoding is sent in the HTTP header... but
if that is not done (and this is the case in a large number of
documents), then the browser has to resort to character encoding
sniffing and usually gives up after the first 1024 bytes (but even that
isn't a spec requirement).

The potential solutions that were floated yesterday were:

1. Include a BOM at the beginning of the document.
2. Re-declare <html prefix=...> after character encoding information via
   <meta charset> has been specified.
3. Assert that all RDFa documents must be encoded in UTF-8.

None of these are viable options. We may even want to tell people that
they are advised to not put @prefix in the root element if their
document encoding character set isn't correctly specified in the HTTP

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
Received on Thursday, 18 August 2011 13:54:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:25 UTC