new issue? squatting on link relationship names, x-tokens, registries, and URI-based extensibility

When somebody wants to deploy a new idiom or a new term in the
Web, they're more than welcome to make up a URI for it...

"[URI] is an agreement about how the Internet community allocates names
and associates them with the resources they identify."
  -- http://www.w3.org/TR/webarch/#id-resources

We particularly encourage this for XML vocabularies...

"The purpose of an XML namespace (defined in [XMLNS]) is to allow the
deployment of XML vocabularies (in which element and attribute names are
defined) in a global environment and to reduce the risk of name
collisions in a given document when vocabularies are combined."
 -- http://www.w3.org/TR/webarch/#xml-namespaces

But while making up a URI is pretty straightforward, it's more
trouble than not bothering at all. And people usually don't do any
more work than they have to.

There is a time and a place for just using short strings, but
since short strings are scarce resources shared by the global
community, fair and open processes should be used to manage them.
Witness TCP/IP ports, HTML element names, Unicode characters, and
domain names and trademarks -- different processes, with
different escalation and enforcement mechanisms, but all accepted
as fair by the global community, more or less, I think.

The IETF has a tradition of reserving
tokens starting with "x-" for experimental use, with the expectation
that they'll shed the x- prefix as they're registered by IANA.
But it's not really clear how that transition happens.

Witness application/x-www-form-urlencoded. A horrible name, perhaps,
but nobody has enough motivation to change it. It's been all the
way thru the W3C process... twice now: once for HTML 4 and again
in XForms. Hmm... I wonder if it's registered... nope.
http://www.iana.org/assignments/media-types/application/

A pattern that I'd like to see more of is
  1. start with a URI for a new term
  2. if it picks up steam, introduce a synonym that
     is a short string thru a fair/open process

I'm not sure where the motivation to complete step 2 will come
from, but if it doesn't come at all, that's OK. Stopping with a
URI term is a lot better than getting stuck with something
like x-www-form-urlencoded.

Lately I'm seeing quite the opposite. The HTML specification
includes a hook for grounding link relationships in URI space
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3

but people aren't using it:

"when Google sees the attribute (rel="nofollow") on hyperlinks, those
links won't get any credit when we rank websites in our search results."
 --
http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

"By adding rel="tag" to a hyperlink, a page indicates that the
destination of that hyperlink is an author-designated "tag" (or
keyword/subject) of the current page."
http://developers.technorati.com/wiki/RelTag

"What are the prefetching hints? 
        
        The browser looks for either an HTML <link> tag or an HTTP Link:
        header with a relation type of either next or prefetch."
  -- http://www.mozilla.org/projects/netlib/Link_Prefetching_FAQ.html


Google is sufficiently influential that they form a critical mass
for deploying these things all by themselves. While Google enjoys
a good reputation these days, and the community isn't complaining
much, I don't think what they're doing is fair. Other companies
with similarly influential positions used to play this game
with HTML element names, and I think the community is decided
that it's not fair or even much fun.

Deployment of the technorati RelTag thingy seems much more
grass-roots, peer-to-peer. But even so, it's only a matter
of time before we see a name clash. So perhaps it's fair,
but it doesn't seem wise.

I think all three of these are cases of squatting on the
community resource of link relationship names.

Should all new link relationships go thru the W3C HTML Working
Group? No, of course not. The profile mechanism is there
to decentralize the process.

Should W3C run a registry of link relationship names?
That seems boring and inefficient, to me. It can't possibly
cost less time and effort to apply for a W3C-registered
link relationship name than it can to reserve a domain name
and run a web server, can it? If Google and Mozilla really
want the community agree to these short names, I'd be
happy to see them use the W3C member submissions process.
 http://www.w3.org/Submission/


OK, now that I've written it down, yes, I think that's a
reasonably coherent request for a new TAG issue.

Nearby issues include:

uriMediaType-9 : Why does the Web use mime types and not URIs?
http://www.w3.org/2001/tag/issues.html?type=1#uriMediaType-9

URNsAndRegistries-50: URNs for namespace names used in XML formats
http://www.w3.org/2001/tag/issues.html?type=1#URNsAndRegistries-50

XMLVersioning-41: What are good practices for designing extensible XML
languages and for handling versioning?
http://www.w3.org/2001/tag/issues.html?type=1#XMLVersioning-41

nameSpaceState-48: Adding terms to a namespace
http://www.w3.org/2001/tag/issues.html?type=1#nameSpaceState-48

and if one of the people working on findings about
those issues is happy to include this topic of squatting
on link relationship names, then perhaps we don't need
a new issue.

I vaguely recall discussions of URI-based pivot points
of extensibility, though I can't confirm from records.
I think it's an important topic and
isn't sufficiently covered by the 2004 webarch REC.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 6 April 2005 16:18:13 UTC