Graham wrote:
I'd like to propose an alternative to atom:modified? I've mentioned this a couple of times before over the last two years, but anyway:
The only properties of atom:modified we're interested in are: 1) That different versions have different dates 2) Sorting chronologically puts the versions in the correct order
This is to say, the absolute value of the date is irrelevant. The only thing that matters is whether it is before, after or the same as other dates that have appeared on a particular entry.
Proposal:
atom:version
atom:version is a Date Construct that determines the chronology of instances of atom:entry. Each time an atom:entry is modified, atom:version MUST be given a chronologically later value than other values than have appeared in any atom:entry with the same value for atom:id.
The value does not need to correspond to any particular event in an entries life-cycle. Suitable values include date of last modification, or the date the atom:entry is generated by an Atom producer.
Is this plausible?
Potential concerns / observations:
1) cvs versions are numbered with things like 1.99 and 1.103. This
makes such versions unsuitable for this purpose. How do we make
this clear? 2) in the general case, sorting of unicode is culturally sensitive.
This isn't a concern for RFC 3339 based dates given the constrained
set of characters that that grammar permits. 3) Perhaps version/modified need not be mandatory except in those
instances where entries with duplicate ids are present in a feed? 4) No semantics can be inferred by two different entries with two
different ids sharing the same version.- Sam Ruby
