Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA

Ian Hickson <> Tue, 10 August 2010 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4459B3A6AD2 for <>; Tue, 10 Aug 2010 13:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BYMYaRFGcQmB for <>; Tue, 10 Aug 2010 13:51:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E64B3A6AD8 for <>; Tue, 10 Aug 2010 13:51:12 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B6FE15E0069; Tue, 10 Aug 2010 13:51:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns;; b=ddpmVmS7p41jtEplJ0KW6aTmpW/+/ zqKzxlh3I6Vjb2vI/WavWb66nAlMsa/ibcew+0lKYVjUbu4Qg7GgQ/9COvHxA2xM 1aVpg+p8dlafQWVc3RlRds7mc7FCbeqxO/8gNRIAEbpMBADQuzwkSMhAMSLMaFC0 Od0BGLk9k2G8lM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type;; bh=o1PVeo1VKf3ml9m4P+Un3jNaSZk=; b=fUO /kUfzv58p9jNwyTp8YAR57WGxecWx3O4GUEQOzqL5Amk5JPKM7YIY6Y18nEQlMMj 23mGNBHQaTL9/kEJRLDz5oO9VwSEh0E6j1LLiMz+pZFsJnRydoWlXUf4HLuGoEHK 2a9ThYFA3+RL2G9WqLPrZE581ueLZJTrgbLWqgpk=
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id A94D05E005F; Tue, 10 Aug 2010 13:51:47 -0700 (PDT)
Date: Tue, 10 Aug 2010 20:51:47 +0000
From: Ian Hickson <>
To: Julian Reschke <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <1281459315.701.260.camel@chacal> <> <>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Aug 2010 20:51:14 -0000

On Tue, 10 Aug 2010, Julian Reschke wrote:
> >
> > Because it wouldn't make any sense on<link> as defined. This is why 
> > conformance is an inherent part of the keywords. In fact, I am 
> > surprised other uses of these keywords don't have the same problem. 
> > For example, if we added "bookmark" (replacing the current 
> > registration which doesn't match real world usage of the keyword) to 
> > the registry, then a user agent would be unable to properly process it 
> > in an Atom environment or when used with a Link: header.
> So maybe the "new" definition is simply incorrect. Why did you change 
> it?

To match real world usage.

> > > - Unconvinced that<a>  and<link>  require different treatment.
> > 
> > The simplest example of this is rel=stylesheet.
> That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could*
> be defined (scoped CSS comes to mind).

Well that's as may be, but currently reality isn't so. I presume you would 
agree that the registry should match reality.

> > > - Unconvinced that the default of "no" for<link> is right. If 
> > > somebody defines a link relation, and it doesn't make sense 
> > > on<link>, then it appears that something is very wrong with the 
> > > proposed semantics of the link relation.
> > 
> > There are very few where this is the case, but I don't see why that 
> > would mean a relation where this is the case is wrong.
> If there are few, then this implies the default should not be "no".

The "default" is merely a shorthand for not having to list every current 
relation and its new value; if you would rather I just list every relation 
I would be happy to do that.

> That being said, I don't see anything in the definition of <link> which 
> makes it different from what the HTTP Link header, for instance, 
> defines. Maybe you could elaborate?

Elaborate on what? I didn't mention Link: headers here? I would not want 
to presuppose how Link: headers should work; I've already sent feedback on 
the Link: header work which has been rejected (e.g. the HTTP Link: header 
doesn't define how rel=stylesheet should work with the CSSOM, but that is 
apparently out of scope of the Link: header), so clearly my understanding 
of that issue is not complete. As such, I would certainly not want to 
presume to apply conformance requirements on usage of that header.

> > The issues had in fact been decided in an appropriate venue; I was 
> > surprised to find any resistance in the registration.
> There was no conscious decision. As a matter of fact, there's a related 
> bug (<>), which 
> hasn't been processed yet.

That's a different venue. The registration template links to a WHATWG 
specification, where this issue was considered and decided appropriately.

> That's why we'd want the links to point at a published draft, not at 
> work-in-progress.

The WHATWG spec is a published draft standard.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'