W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: RDF 1.1 Lite Issue # 2: property vs rel

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 25 Oct 2011 11:00:55 +0300
Message-ID: <CAJQvAuciO7AzWEyJRkoGM7sR6=rCBHNRLxQApaTyu2BHULnrSg@mail.gmail.com>
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
Received on Tuesday, 25 October 2011 08:01:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC