Robert Sayre wrote:
>Versioning problems aren't solved by timestamps.
I don't understand why this "version" issue keeps coming up. It
should be apparent to everyone that there is NO relationship between
timestamp and version. Timestamps have only two functions:
1. Different timestamps indicate different instances of an entry.
2. Timestamps allow assumptions concerning temporal ORDER or
sequence to made
It is totally reasonable for me to develop a "V1.0" followed by a
"V2.0" which is then followed by a "V1.1" -- if I have a reasonably rich
versioning scheme. If I then order-by-version, I would have the ordered set
"V1.0," "V1.1," "V2.0". However, if I order-by-time, I have the ordered set
"V1.0," V2.0," "V1.1".
I believe that atom:modified is intended only to permit
order-by-time. Certainly, that is all that is needed to address the vast
majority of use cases for which atom:modified has been declared useful.
Atom:modified is intended to allow processors to compare two non-identical
instances of a single entry and determine the order in which they should be
considered to have been created. Atom:modified allows us to say "This entry
is considered to have been created after that entry." Atom:modified does not
permit us to make any statements concerning "versions" or "variants."
It is possible that some confusion is being introduced here since
one may notice that if a very simple, single-line-of-descent versioning
scheme is used, the time-ordered sequence of instances will be identical to
a version-ordered set of instances. However, this is merely an anecdotal
observation that applies to only one of many possible classes of versioning
policy. There is no general correlation between temporal order and version
order that applies across all versioning policies. Any correlation between
temporal-order and version-order should generally be considered coincidental
and not interesting.
Knowledge of temporal order is extremely useful information that can
be usefully exploited by Atom Processors to deliver a number of capabilities
demanded by a variety of users. However, the current definition of Atom
(since it doesn't support atom:modified) does not permit general temporal
ordering of entries even when they are all published in a single feed. At
best, the current definition only allows us to temporally order sets of
entries that have the same atom:updated value. However, we have no means of
determining sequence or temporal ordering of the elements of a set whose
members share the same atom:updated value. This inability to order elements
of such sets is a significant weakness in Atom in that it introduces
ambiguity.
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values. This
has nothing to do with versioning.
bob wyman
