- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 24 May 2009 16:16:25 +0300
- To: Shelley Powers <shelleyp@burningbird.net>
- 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>
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 hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Sunday, 24 May 2009 13:17:13 UTC