- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 25 Oct 2011 11:00:55 +0300
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: Guha <guha@google.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Vocabularies <public-vocabs@w3.org>, HTML Data Task Force WG <public-html-data-tf@w3.org>
On Sun, Oct 23, 2011 at 3:28 AM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > There are probably some corner cases that would need to be worked out, but > by limiting this to the HTML+RDFa definition, we avoid backwards > compatibility issues with RDFa 1.0 and get that much closer I think efforts to fix RDFa are doomed if they try to be backwards compatible with RDFa 1.0 in the sense that any RDFa 1.0 input you can construct produces the same triples in an RDFa_fixed processor as it would in an RDFa 1.0 processor. If you choose that route, you don't get to *remove* any of the badness of RDFa 1.0. And *removing* badness of RDFa is the kind of fixing RDFa needs. (For example, the obvious conclusion one should make about the statistic Guha provided is that the rel attribute shouldn't participate in RDFa processing.) Note that HTML5 does not try to be backwards-compatible with the HTML 4.01 spec. It tries to be compatible with existing content. That is, it tries to be compatible with content that's actually on the Web--not with content that one could construct based on the HTML 4.01 spec. For any efforts to "fix" RDFa, I think it's a fatal mistake to require backwards compatibility with RDFa 1.0 (the spec). At most it would make sense to require compatibility with the most common flavors of published content that purports to use RDFa 1.0. (I say "purports", because RDFa 1.0 doesn't officially exists for text/html but the published content is practically fully text/html.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 25 October 2011 08:01:30 UTC