My thought currently is that atom:updated by being the sole date in
atom is in
fact what people are thinking of as atom:modified.
It is just specified very flexibly and constrained not by language
but by how it will
be used. The game of publishing entries will push people to be
reasonably precise about
what they consider to be a change:
- if they don't, their entries may be lost
- creating a new time stamp is so easy, there is no reason not
to change the
time stamp by default
So I am in fact -1 on atom:modified.
It would be silly to have 2 dates in atom, we would then just have
more confusion and
corner cases. The more precise date would inevitably be considered
the real one, and the
other one ignored in any case. Adding a more precise definition of
what constitutes a
change is beyond the ability of this working group given the way it
has to come to an
agreement.
On 24 May 2005, at 01:17, David Powell wrote:
When a publisher updates an existing entry, the value that they put in
atom:updated combines three parameters:
a) The last modified date of the entry (ie: the value that would go
into atom:modified if it existed)
b) The atom:updated value of the previous instance.
c) Whether the publisher's opinion is that the change is significant.
(some publishing systems may not allow the publisher to express
this opinion - in that case, this parameter will be hard-coded)
The publisher chooses whether the new atom:updated value should be the
current modification date, or the previous atom:updated value based on
whether, in their opinion the change is significant.
If a publisher wants to change an entry, and wants to
indicate that in their opinion the change was not significant, the
current draft allows them to do this by publishing a new version of
the entry with the same value of atom:updated as the previous version.
