- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 26 May 2009 08:47:10 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Manu Sporny wrote: >> "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). What would be the procedure to update the spec? Who owns it? > 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 > tutorials. That sounds backwards. I think what happened is that there is no registration procedure, there never was one, and thus people, well, do not register link relations. That's not a proof that no procedure is needed. > ... >>> 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. > ... The IETF I-D proposes a registry for short, widely used names, and IRIs for everthing else (the latter do not need registration). This is the same approach as the one used in Atom (RFC 4287). BR, Julian
Received on Tuesday, 26 May 2009 06:48:04 UTC