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

Re: HTML 4 Profile for RDFa

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 24 May 2009 16:16:25 +0300
Cc: Philip Taylor <pjt47@cam.ac.uk>, 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>
Message-Id: <7BD4D657-11FB-434B-B126-FC7C57205A87@iki.fi>
To: Shelley Powers <shelleyp@burningbird.net>
On May 24, 2009, at 15:59, Shelley Powers wrote:

> Henri Sivonen wrote:
>> On May 23, 2009, at 19:49, Philip Taylor wrote:
>>> * 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.
>> * Use a mechanism other than CURIEs to turn attribute values into  
>> absolute IRIs.
>> As it happens, the microdata to RDF conversion already has a  
>> mechanism for mapping itemprop values to absolute IRIs without  
>> prefix-based indirection. (And itemprop works nicely with  
>> Selectors, too, allowing styling based on microdata, while  
>> Selectors don't support matching on expanded CURIEs, so styling on  
>> RDFa would need to depend on the prefixes that aren't supposed to  
>> be significant.) In fact, even RDFa itself has a non-CURIE-based  
>> mapping from attribute values onto IRIs for traditional rel tokens.
> I wouldn't make an assumption that the microdata section will exist  
> going into the future. Regardless, discussions of Microdata are  
> irrelevant to discussions of RDFa, don't you think?

Microdata shows that it's possible to formulate a non-CURIE mapping  
from attribute values onto RDF properties. The proof of possibility  
wouldn't go away even if the section in the spec went away.

>> http://rdfa.info/wiki/Rdfa-in-html-issues currently has 12 issues.
> And how many of these are related to bugs in the processors, and how  
> many are actually issues with RDFa?

Since RDFa isn't defined for text/html, one might take a position that  
it's a bug for a processor to try to process text/html resource  
representations as having embedded RDFa. Alternatively, one might say  
that the failure to cover text/html is an issue with RDFa.

> And how many of these are related to underlying problems with the  
> DOM, not directly with RDFa?

The underlying problems of the DOM are a given (especially when part  
of the RDFa community have taken a position that no browser changes  
are needed). It is then a major flaw of RDFa that it has been written  
in such a way that the problems of the DOM end up being touched and  
haven't been properly avoided.

Henri Sivonen
Received on Sunday, 24 May 2009 13:17:12 UTC

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