W3C home > Mailing lists > Public > public-html@w3.org > February 2009

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 27 Feb 2009 20:17:21 -0500
Message-ID: <49A890A1.6020106@intertwingly.net>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Ben Adida <ben@adida.net>, noah_mendelsohn@us.ibm.com, Henri Sivonen <hsivonen@iki.fi>, Mark Nottingham <mnot@mnot.net>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, public-xhtml2@w3.org, "www-tag@w3.org WG" <www-tag@w3.org>
Julian Reschke wrote:
> Ben Adida wrote:
>> Julian Reschke wrote:
>>>> how @rel is interpreted. You can't interpret @rel blindfolded.
>>> But I'd like to.
>>
>> I don't think RDFa is the technology that's stopping you here. The
>> existing state of the web and HTML is already preventing it.
>>
>>> WRT profile; I see how this can work for a single profile URI, but it
>>> does not scale, so I'm not sure how this is supposed to help with mixing
>>> relations from several profiles (namespaces) in a single document.
>>
>> Far be it from me to defend the @profile approach to web-scale data :)
>> But, to be fair, @profile does allow for a space-separated list of 
>> values.
> 
> Yes, but how does this help in this case?
> 
> If I have
> 
>   <head profile="http://example.com/ http://example.org/">
> 
> and
> 
>   <a rel="foobar">
> 
> ...how do I find out which profile/namespace foobar belongs to? It 
> doesn't solve the disambiguation problem.

I'll also mention that fragments of [X]HTML often appear in places like 
XMPP and Atom.  Places where a <head> element generally don't appear.

A typical content management system like WordPress, templating languages 
like PHP, and even lowly Planet aggregating software often are faced 
with the problem of collating multiple fragments and placing them on a 
single page.

We are not talking about obscure tags here, we are talking about 
attributes that may be found on the <a> tag.

- Sam Ruby
Received on Saturday, 28 February 2009 01:20:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:32 GMT