W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > March 2009

Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

From: Rob Sayre <rsayre@mozilla.com>
Date: Sun, 01 Mar 2009 14:13:33 -0500
Message-ID: <49AADE5D.5090507@mozilla.com>
To: Dan Brickley <danbri@danbri.org>
CC: Sam Ruby <rubys@intertwingly.net>, Mark Nottingham <mnot@mnot.net>, Ben Adida <ben@adida.net>, Manu Sporny <msporny@digitalbazaar.com>, "www-tag@w3.org WG" <www-tag@w3.org>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, public-xhtml2@w3.org
On 3/1/09 2:09 PM, Dan Brickley wrote:
>> Do you mean it won't work technically, or that it would be using the
>> attributes in a way that's unintended? RDFa already uses XML Namespaces
>> and HTML in ways that those specifications don't cover. What's different
>> about my example?
> This option has been bounced around a few times on the HTML and WHATWG 
> lists. The general consensus seemed to be that this wasn't what data- 
> attributes were intended for. Of course the HTML5 spec is still in 
> flux, and they could be redefined to do this kind of thing too. 
> Whether that would be a good idea, I don't know.

My question was about what's different from the current RDFa strategy of 
using other specifications in ways that weren't intended. Even in XHTML, 
using QNames in content is a flagrant layering violation, and certainly 
unintended by XMLNS. So I think your answer didn't really address my 

However, unlike XMLNS, we could change the HTML5 text. Those attributes 
are obviously going to leak all over the place, so I can't see how it 
would matter.

Here's my suggestion:

"Custom data attributes store data for which there are no appropriate 
attributes or elements. Authors should be aware that these HTML5 has no 
facilities to protect against naming collisions in the data- namespace."

data-rdfa- seems very unlikely to collide with anything.

- Rob
Received on Sunday, 1 March 2009 19:14:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:01 UTC