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

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