Re: PaceArchiveDocument posted

[Antone Roundy]

On Monday, February 7, 2005, at 10:26  AM, Bob Wyman wrote:
Antone Roundy wrote:
        <entry>
                <id revision="3">foo:bar/a</id>
                ...
        </entry>
...where @revision is a number whose only requirement is that the
number for a later revision be greater than the number for an
earlier revision, but skipping numbers is allowed.
	Providing an explicit revision number exclusively in atom:archives
has both advantages and costs.
	If we assume that revision numbers start at 0 or 1 and increase
monotonically, then revision numbers gets us:
	1. The ability to name or explicitly identify different versions of
an entry.
	2. The ability to determine the order in which entries were written
-- independent of document order.
	3. The ability to detect "missing" entry versions.
	The cost of the three benefits above is, of course, the increased
complexity that comes from needing to maintain the version number 
associated
with an entry.
Only if the version number for a particular Entry Representation needs 
to remain constant.  I'd be fine with it either way--simplicity and 
only #2 (and limited #1--you can do it within the context of a 
particular instance of the archive, but can't be sure it won't change 
when you download the archive again) vs. storing the version number and 
getting all 3.

        The first two benefits of version numbers can be had without a
requirement for maintaining any state if we make the version number a
DateTime.
Of course, you'd have to store the DateTime.  It's more likely that 
people are already doing that, so for those that are, this would be 
preferable.  Those who aren't are likely not storing the historical 
states of the entry at all.

	Is a revision attribute such a "bad thing" that it is really
necessary to increase the complexity of the system by requiring that 
it be
stored and maintained external to the feed document itself? Wouldn't 
it be
easier to just allow sites that archive to include the revision number 
in
their feed documents?
I'd have no problem with allowing that.
	Given the two arguments above, it would seem that atom:modified
(must be updated on the change of any byte in an entry) would provide 
all of
the benefits that appear to be desired with the exception of "missing" 
entry
detection.
True.  Rather than going back into the whole discussion of dates, we 
could let people who want to get benefits #1 and #2 can store 
dc:modified (since atom:modified) doesn't currently exist, and those 
who don't do that can either invent their own extension like @revision. 
 So archive documents as defined in Atom wouldn't include either, and 
the market would show us which would prevail.

I'm feeling a little apathetic about exactly how we do it at the moment.