W3C home > Mailing lists > Public > public-rdfa@w3.org > May 2009

Re: HTML 4 Profile for RDFa

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 23 May 2009 20:05:57 +0200
Message-ID: <4A183B05.1080108@gmx.de>
To: Philip Taylor <pjt47@cam.ac.uk>
CC: Sam Ruby <rubys@intertwingly.net>, Shane McCarron <shane@aptest.com>, RDFa Community <public-rdfa@w3.org>, "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Philip Taylor wrote:
> ...
> Hmm, maybe a better example of what I intended is:
>   <div xmlns:t="test1:">
>     <div xmlns:T="test2:">
>       <span property="t:x T:y">Test</span>
>     </div>
>   </div>
> which is well-formed XML and has a clear definition in RDFa-in-XHTML, 
> but the defined behaviour is impossible to reproduce in text/html 
> (because xmlns:t and xmlns:T (and XMLNS:T) are parsed identically by an 
> HTML parser and there's no way to distinguish them afterwards).
> RDFa-in-text/html could:
> * Assume attributes are all treated as lowercase (breaking <div 
> xmlns:T="..." property="T:..."> which works in XHTML);
> * Say CURIEs (in both XHTML and HTML) match prefixes case-insensitively 
> (breaking compatibility with current implementations);
> * Change text/html parsing to preserve attribute case (breaking 
> compatibility with current parsers);
> * Use some other prefix-binding mechanism (in both XHTML in HTML) like 
> prefix="t=... T=..." instead of xmlns:t="..." (breaking current 
> implementations and deployed content, but avoiding the mess of parsing 
> differences between XHTML and HTML).
> I can't think of any other solutions, so something is going to break no 
> matter what is chosen.

It's clear that if RDFa is to be used with prefix declarations done with 
xmlns, then mixing uppercase and lowercase declarations is not going to 

I think restricting prefixes to be lower-case (insert proper Unicode 
terminology here) would be acceptable; it's easy to live with, and 
avoids introducing yet another prefix declaration mechanism.

BR, Julian
Received on Saturday, 23 May 2009 18:06:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:43 UTC