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

Centralized LinkType registries (was Re: RDFa in HTML issues wiki page created)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 25 May 2009 20:39:40 -0400
Message-ID: <4A1B3A4C.3010706@digitalbazaar.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Julian Reschke wrote:
> Manu Sporny wrote:
>>> So, what's the registration procedure for
>>> <http://www.w3.org/1999/xhtml/vocab/> -- and who's going to maintain it
>>> once the WG ceases to exist?
>> Which WG? Currently, the registration procedure for HTML4 is a done deal
>> (not more LinkTypes for HTML4). For XHTML1.1 and XHTML2, the LinkTypes
>> are defined in the language document. For HTML5, they're in a wiki.
> "Done deal" -- that doesn't work for me. People use new link relations
> all over the place, be it in XHTML1.* or HTML4, but they aren't registered.

What I meant by "done deal" was that the HTML4 LinkType relationships in
the HTML4 spec haven't changed (AFAIK) in some time. I don't think there
are any plans for them to be updated (again, in the spec - not in the wild).

> That may be because there's no way to register them. So claiming
> extensions aren't possible isn't helpful, when reality proves they are
> possible.

I wasn't claiming that at all - just expressing that the mechanism to
add new @rel values is probably not going to be the HTML4 spec, which is
validated by the fact that Google et al have not gone to the trouble of
trying to update the HTML4 spec with the new LinkTypes, but instead have
asked others to use these new LinkTypes through blogs and web developer

>> The W3C has typically maintained these documents in the past, and I
>> don't see any reason why that would change. Even if we have a LinkType
>> registry, I would expect the W3C to manage that.
> It didn't since HTML4 was published, so what does make you think it'll
> work better in the future?

IF there is a mechanism that creates a centralized LinkType registry
under the W3C/IETF, it would be a bad idea not to put the necessity of
management in the charter of the group that manages that registry.

Besides, this type of housekeeping happens all the time at W3C, for
example (note the addition of RDFa to the page and the recent addition
of @role values):


I'm not saying that this is the best way forward. Maintenance does,
however, happen to documents that are understood to be maintainable.

>>> What we need is a format-neutral registry (I want to be able to express
>>> link relations from non *HTML documents as well), and a registry that
>>> works in practice.
>> I'm not particularly opposed to that idea - although, I know others that
>> are opposed to the notion of a centralized LinkType registry.

You know - this whole concept of a centralized LinkType registry is a
bit moot if one were to just use RDFa to extend the LinkTypes. Afterall,
that's sort of the point of RDFa - you don't need to centralize anything
nor ask anybody for permission to extend the list of available
LinkTypes. Even if you hate CURIEs, using full URIs in @rel values would
be one way to not require a centralized registry of any sort.

If one wants to extend all (X)HTML LinkTypes, say from the year 2010
onwards, we could ask language designers to just use RDFa and make the
whole concept of LinkTypes legacy/deprecated behavior. That would allow
things like, rel="search:robots" and rel="google:mindmeld" without
requiring the use of any sort of centralized LinkType registry and long
arguments as to whether the @rel value is "useful".

We should be careful to not over-engineer the solution to this -
especially when it seems as if we already have a solution that will
address the problem that the "centralized LinkType registry" tries to solve.

-- manu

Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: A Collaborative Distribution Model for Music
Received on Tuesday, 26 May 2009 00:45:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:45 UTC