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: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 15 Apr 2010 13:10:12 +0200
Message-ID: <4BC6F414.2090305@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: Sam Ruby <rubys@intertwingly.net>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
On 15.04.2010 12:09, Maciej Stachowiak wrote:
> On Apr 15, 2010, at 2:56 AM, Julian Reschke wrote:
>> I agree that it's not easy to apply Atom requirements to every
>> possible use case, some of which may not have been considered when
>> writing the spec. Pointing out areas where that is the case is
>> instructive, but not necessarily helpful in talking about the concrete
>> case here.
>> So I'd recommend to focus on those criteria which *are* clear. And I
>> maintain that an atom:id that varies on multiple runs of a given
>> algorithm for the same source and the same converter (as in same code,
>> same config, same machine, same user, ...) definitively is broken.
> Would guaranteeing the same ID in only that exact case be conforming to
> Atom? (i.e. if you change any of the things you mentioned, the resulting
> IDs may change).
> The reason I ask is because I think it *is* practical to make just this
> limited case a MUST-level requirement without forcing the embedding of
> atom:ids in the input HTML. The converter would just need to hash on
> some combination of the data you cited when producing the ID. If it
> includes the local filename of the HTML file, the contents of the HTML
> file, the MAC address of the system it's running on, and the username of
> the user running it, then it's also effectively impossible for it to
> accidentally assign the same ID to different entries.
> ...

If the hash is based on the whole HTML document, or just the entry, it 
will change more frequently then it should.

I think you need something globally unique for the HTML document. The 
for every entry, something locally unique plus reliable information to 
produce the atom:updated entry. If you have all of that, generating 
stable atom:ids per entry should be possible.

Best regards, Julian
Received on Thursday, 15 April 2010 11:10:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC