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

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

Hence the SHOULD. It's almost like a MUST, but it acknowledges that it may 
not be possible to implement the requirement in some cases.

It should be noted that since this is still a MUST in the Atom spec, the 
implementation is still non-conforming. So I really don't see the problem.

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

Received on Wednesday, 14 April 2010 22:09:42 UTC