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

Ian Hickson <ian@hixie.ch> Tue, 10 August 2010 20:51 UTC

Return-Path: <ian@hixie.ch>
X-Original-To: link-relations@core3.amsl.com
Delivered-To: link-relations@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4459B3A6AD2 for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 13:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level:
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYMYaRFGcQmB for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 13:51:12 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 4E64B3A6AD8 for <link-relations@ietf.org>; Tue, 10 Aug 2010 13:51:12 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id B6FE15E0069; Tue, 10 Aug 2010 13:51:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=ddpmVmS7p41jtEplJ0KW6aTmpW/+/ zqKzxlh3I6Vjb2vI/WavWb66nAlMsa/ibcew+0lKYVjUbu4Qg7GgQ/9COvHxA2xM 1aVpg+p8dlafQWVc3RlRds7mc7FCbeqxO/8gNRIAEbpMBADQuzwkSMhAMSLMaFC0 Od0BGLk9k2G8lM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=o1PVeo1VKf3ml9m4P+Un3jNaSZk=; b=fUO /kUfzv58p9jNwyTp8YAR57WGxecWx3O4GUEQOzqL5Amk5JPKM7YIY6Y18nEQlMMj 23mGNBHQaTL9/kEJRLDz5oO9VwSEh0E6j1LLiMz+pZFsJnRydoWlXUf4HLuGoEHK 2a9ThYFA3+RL2G9WqLPrZE581ueLZJTrgbLWqgpk=
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id A94D05E005F; Tue, 10 Aug 2010 13:51:47 -0700 (PDT)
Date: Tue, 10 Aug 2010 20:51:47 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <4C61A834.40803@gmx.de>
Message-ID: <Pine.LNX.4.64.1008102043220.11992@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1008090401280.7470@ps20323.dreamhostps.com> <9CDE7636-3E12-48AA-A351-FDD432112978@mnot.net> <1281459315.701.260.camel@chacal> <Pine.LNX.4.64.1008101738070.22575@ps20323.dreamhostps.com> <4C61A834.40803@gmx.de>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: link-relations@ietf.org
Subject: Re: [link-relations] app data wrt HTML usage, was: NEW APP DATA
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=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 (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10172>), 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
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'