W3C home > Mailing lists > Public > www-tag@w3.org > April 2005

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 11 Apr 2005 23:44:27 -0700
Message-Id: <9e89c1b0c15ddc9aab3844f29012030e@mnot.net>
Cc: www-tag@w3.org
To: Dan Connolly <connolly@w3.org>

This is very timely; the IETF ATOMPUB WG is proposing an Atom-specific  
link relation registry as well. I think it would be good to get W3C  
review of it, especially if there are coordination issues with the  
registry for HTML, etc. (i.e., should they be separate, or one and the  
same, or...).

Atom does take an interesting approach WRT what you discuss below; the  
content of @rel can have two syntactic forms; it can either be an  
absolute URI, or it can be a token which is treated as a URI-reference  
with a fixed base (that of the IANA registry for that token namespace).  
In this fashion, commonly used relations have a 'shortcut' form in the  
registry, and people wanting to define their own relations just use an  
absolute URI in their namespace. There are still transition issues, but  
at least you don't have collisions.


P.S. QNames (in content) are Evil.


On Apr 6, 2005, at 9:18 AM, Dan Connolly wrote:

>
> 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
>
>
>
>

--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 12 April 2005 06:44:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:34 GMT