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

On 04/14/2010 06:09 PM, Ian Hickson wrote:
> On Wed, 14 Apr 2010, Sam Ruby wrote:
>> On 04/14/2010 05:25 PM, Ian Hickson wrote:
>>> On Wed, 14 Apr 2010, Sam Ruby wrote:
>>>>
>>>> If there is a consensus to fix these and other bugs, then I would
>>>> support an Atom mapping remaining in the W3C HTML5 spec.
>>>
>>> I'm happy to fix real bugs, if they are reported. Bug 7806, however,
>>> has already been fixed to the extent possible in the HTML5 spec. What
>>> Julian escalated was not the original reported bug, which was in fact
>>> fixed; what he escalated was a request to say that if an
>>> implementation didn't conform to the Atom specification in one very
>>> specific case that is arguably not always possible to achieve, that
>>> implementation should _also_ be considered not conforming to the HTML
>>> specification. This seems to me to be idealistic language lawyering
>>> with no value.
>>
>> Speaking again as only a member of the Atom community: given the
>> importance that entry ids have in enabling user agents that process Atom
>> feeds to match entries in the feed against what they have seen before, I
>> personally believe that it is actively harmful for feeds to be produced
>> by any software that can't guarantee that they produce the same ID given
>> the same input.
>>
>> Reading through the entire bug, and in particular comment #23, I think
>> the spec is making the wrong tradeoff, and I suggest you reconsider the
>> presumption.  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.
>>
>> FWIW, I don't see dereferenceable as mandatory.
>
> 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

> 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.

- Sam Ruby

Received on Wednesday, 14 April 2010 22:34:13 UTC