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: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 15 Apr 2010 03:09:10 -0700
Cc: Sam Ruby <rubys@intertwingly.net>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
Message-id: <369603A5-9224-41EC-BD51-0B20E59DF724@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

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.

Regards,
Maciej
Received on Thursday, 15 April 2010 10:09:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC