Subject: community review norms, link relationships

From: Dan Connolly <[email-masked]>
Date: Mon, 26 Mar 2007 08:44:57 -0500

In our recent teleconference, I brought up some concerns
about large-scale release of stuff on the Internet
without community review.

John, the main case that got me thinking about this
was Google's January 2005 introduction of rel="nofollow".

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

I wrote to the TAG about that, and about a couple other
related cases (Mozilla's rel="prefetch" and Technorati's rel="tag")
and about difficulties with the x- mechanism in
practice, especially in the case of application/x-www-form-urlencoded.
http://lists.w3.org/Archives/Public/www-tag/2005Apr/0033.html
(a copy is attached).

Is that enough detail for you to follow up, John?

Oops; I see that in reply, mnot suggested W3C review of the Atom link
relationship registry mechanism at the time (also attached), but
I neglected to follow up on it.

The TAG did create a new issue, though I'm not fond of the name
and we haven't made much progress on it since...
standardizedFieldValues-51: Squatting on link relationship names,
x-tokens, registries, and URI-based extensibility
http://www.w3.org/2001/tag/issues.html?type=1#standardizedFieldValues-51

I also wrote about this stuff in an April 2006 blog item
when SPARQL reached Candidate Recommendation status:
Consensus and community review in open source and open standards
by connolly 2006-04-06
http://dig.csail.mit.edu/breadcrumbs/node/124

"I remember a time though I can't confirm from The Tao of IETF or any of
the other records that I searched when people and companies who wanted
to deploy new technology on the Internet were expected to submit their
proposal for community review before deploying widely."

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
office: tel:+1-617-395-0241
mobile: tel:+1-816-616-6576
mobile: mailto:[email-masked]

Subject: new issue? squatting on link relationship names, x-tokens, registries, and URI-based extensibility
From: Dan Connolly <[email-masked]>
To: [email-masked]
Date: Wed, 06 Apr 2005 11:18:11 -0500
List-Id: <www-tag.w3.org>

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

Subject: Re: new issue? squatting on link relationship names, x-tokens, registries, and URI-based extensibility
From: Mark Nottingham <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: [email-masked]
Date: Mon, 11 Apr 2005 23:44:27 -0700

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/