W3C home > Mailing lists > Public > public-html@w3.org > April 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 16 Apr 2010 14:56:00 +0200
Message-ID: <4BC85E60.6000302@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: "public-html@w3.org WG" <public-html@w3.org>
On 08.04.2010 14:09, Julian Reschke wrote:
> ...
> Below is a slightly updated version, based on feedback from the
> atom-syntax mailing list.
> ...

When I went to the atom-syntax mailing list, people pointed out that 
there may be more problems with the algorithm (but did not provide any 

In the meantime, I realized that the computation of the atom:updated 
timestamp for *updated* entries (see 
surprisingly depends on the presence of <ins>/<del> markup (see 
<http://dev.w3.org/html5/spec/interactive-elements.html#atom>, Step 15/13).

There's nothing really *wrong* about that, but I think the specification 
needs to clarify that if you don't use <ins>/<del> (with timestamps) on 
an updated entry, the generated atom:updated will be incorrect.

Furthermore, Step 15/15:

"If publication date and update date both still have no value, then let 
them both value a value that is a valid global date and time string 
representing the global date and time of the moment that this algorithm 
was invoked."

appears to handle the case where no date information is available at 
all, letting it default to the current date. Again, generating feeds 
where atom:updated varies with every run of the algorithm seems to be a 
bad idea to me and supports the argument that producing output for 
insufficient input data is problematic.

Best regards, Julian
Received on Friday, 16 April 2010 12:56:42 UTC

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