W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 16 Apr 2010 20:38:04 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Edward O'Connor <hober0@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1004162018120.23507@ps20323.dreamhostps.com>
On Fri, 16 Apr 2010, Ian Hickson wrote:
> On Fri, 16 Apr 2010, Tab Atkins Jr. wrote:
> > 
> > "
> > Let id be a user-agent-defined undereferenceable yet globally unique
> > valid absolute URL. The same absolute URL must be generated for each
> > run of this algorithm when given the same input. Let has-alternate be
> > false.
> > 
> > Non-normative note: This may result in a single entry producing
> > different ids, if the contents of the corresponding <article> change
> > often.  This may produce an undesirable user experience in Atom feed
> > consumers, as the single article may exist multiple times in the feed
> > as distinct entries.  It is recommended that authors ensure that one
> > of the previous conditions can be met, ensuring a stable id even if
> > the contents of the article change.
> > "
> 
> Something like the above seems fine to me, so long as we also added an 
> extra clause saying the same URL should also be generated even if the 
> input changed. Otherwise we're actually making the requirement even 
> weaker than what HTML5 has now, which takes us even further away from 
> what was argued Atom requires.

Tab and I discussed this briefly on IRC and maybe the problem is with the 
definition of "same input". As written in the spec I was interpreting it 
as meaning the same source document, possibly with minor changes; Tab's 
note clarified that in his case it meant the same bytes. Clearly the spec 
should be more clear about this.

I'd be fine with the text requiring that user agents apply some sort of 
hashing mechanism the first time they come across an <article> with no ID, 
possibly keyed off the feed's URL, so long as we also allow the user agent 
to return the same URL for the same feed if it changes, but don't require 
it, since that can be impossible to implement.

Basically I'd be ok with splitting the requirement regarding "same input" 
into two, one for how to handle the same URL with the same bytes (as a 
MUST), and one for how to handle less strictly identical input (as a 
SHOULD, since it would likely require storage). Would that work?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 16 April 2010 20:38:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT