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: Wed, 14 Apr 2010 23:08:31 +0000 (UTC)
To: Sam Ruby <rubys@intertwingly.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1004142305260.23507@ps20323.dreamhostps.com>
On Wed, 14 Apr 2010, Sam Ruby wrote:
> > 
> > I don't think that saying that if an implementation doesn't know if it 
> > created a feed before, it should not be allowed to create a feed, is a 
> > good trade-off. I think it would be ignored.
> 
> I suggest that you actually test out how common feed aggregators react 
> when they are presented with the same feed differing only in the entry 
> ids.
> 
> Here's a few quick links for context:
> 
> http://tinyurl.com/y2pobd3
> http://www.hutteman.com/weblog/2003/03/14-51.html
> https://issues.apache.org/jira/browse/ROL-580

I don't think anyone is suggesting that user agents that are able to keep 
the IDs constant should do anything but keep the IDs constant.


> > Basically making this a MUST would lead to implementations having to 
> > violate the spec to do anything useful. When we require that 
> > implementations violate the spec, we lead to them ignoring the spec 
> > even when it's not necessary.
> 
> Based on my experience with feeds (predating Atom), this part of the 
> spec will not be ignored.  Users will write bug reports against the 
> software that implements the algorithm.

If a feed producer has to invent an ID from nothing, and doesn't know what 
ID it used in the past, yet the spec uses "MUST" here, how exactly can it 
do anything _but_ ignore the spec?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 April 2010 23:09:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC