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: Thu, 15 Apr 2010 08:49:22 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Sam Ruby <rubys@intertwingly.net>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1004150838230.23507@ps20323.dreamhostps.com>
On Thu, 15 Apr 2010, Julian Reschke wrote:
> On 15.04.2010 01:08, Ian Hickson wrote:
> > ...
> > > > 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?
> 
> Either you store the ID with the item, or you derive the ID from 
> something sufficiently unique in the set of items, or ... you don't 
> produce an Atom feed.

Storing an ID doesn't work when you're on a read-only medium.

A hashing mechanism by which we can generate an ID from a DOM tree would 
end up making identical posts in unrelated Atom feeds have the same ID, 
and would mean that minor edits (e.g. typo fixes) would generate new IDs, 
both of which would cause all kinds of problems, as Sam pointed out.

Not producing a feed doesn't solve the problem of producing a feed.

Therefore if we make this a MUST in the HTML spec, we are just adding a 
requirement that will in some cases be ignored. This is functionally 
equivalent to a SHOULD, which is what the spec has now.

If you prefer a process-based argument: we can't progress past CR if we 
can't find two interoperable implementations of every feature. If one of 
the features is "you must make consistent IDs for HTML <article>s when 
converting them to Atom, even if they are slightly modified from time to 
time, and even if you have no persistent storage, and you must not create 
IDs that conflict with other entries", then we won't be able to exit CR, 
because that requirement is not implementable.


> What the Atom spec is the result of VERY long discussions, and when it 
> says MUST then it's because the Working Group really wanted it that way.

And nothing we do here can change what the Atom spec says. I don't see the 
problem. We're not making it ok to create invalid feeds. We're just saying 
that if you can't create a valid feed, that's an Atom conformance error 
and not an HTML conformance error.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 April 2010 08:49:52 GMT

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