W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

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

From: Ben Adida <ben@adida.net>
Date: Sat, 28 Feb 2009 08:53:54 -0800
Message-ID: <49A96C22.7000003@adida.net>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: "www-tag@w3.org WG" <www-tag@w3.org>
Roy T. Fielding wrote:
>> It is incorrect to use the term "erratum" to discuss a proposed major
>> change to a REC with numerous implementors and deployed markup that do
>> not consider this an error.
> Oh, please, spare us the grief.  The TAG warned over and over and over
> again that use of QNAMEs (by any name) in contexts where a URI might be
> found would violate Web architecture because they interfered with the
> extensibility of URI schemes.  If software breaks because of RDFa
> arrogance, then so be it.

Hi Roy,

There's an implication in your statement that @rel is a place where one
expects a URI. That's not how @rel was spec'ed to date, and I don't
think that's been the case in most ad-hoc implementations either.

Dublin Core is an early user of @rel, and the values they recommend are:
dc.title, dc.creator, ... In other words, things that look a lot like
prefixed values, only without extensibility.

OpenID also suggests openid.server, openid.delegate, ... Again, prefixed
values where the prefixes are assumed to be drawn from some bucket in
the sky, so no extensibility.

eRDF uses schema.dc, schema.foaf, ... again a number of non-URI prefixed

The only thing we did with RDFa was to try to formalize this use of @rel
and make it extensible by providing a way to define these prefixes in
the markup and map @rel values to URIs. We used a syntax that wouldn't
interfere with the existing ad-hoc uses such as dc.creator and
openid.server, while still being familiar to folks as a prefix
mechanism, thus dc:title.

Received on Saturday, 28 February 2009 16:54:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:27 UTC