Hmm.. I'm sorry but this just seems wierd to me.
<archive>
<head>...</head>
<feed>
<entry>
<id>id:version1</id>
</entry>
</feed>
<feed>
<entry>
<id>id:version2</id>
</entry>
</feed>
<feed>
<entry>
<id>id:version3</id>
</entry>
</feed>
</archive>What is the point of having the feed elements in there at all? If entries are indeed able to stand on their own, why not just go ahead and get rid of the containing feed element altogether? I mean, it is the entries that are being archived, not the feeds that just happened to contain them at some moment in time right?
<archive>
<head>...</head>
<entry>
<id>id:version1</id>
</entry>
<entry>
<id>id:version2</id>
</entry>
<entry>
<id>id:version3</id>
</entry>
</archive>I guess I just don't see the point of archiving the feed.
- James M Snell
Antone Roundy wrote:
I'd rather have held off while we discussed further, but as the deadline is approaching, here it is.
Abstract
Creates a new option for the document element, <archive>, which can contain multiple feeds or instances of the same feed, in order to archive the states of a feed or feeds and the states of the entries published while the feed was in each of those states. Specifies that multiple instances of a resource with the same atom:id is illegal in Feed Documents, Entry Documents, and if PaceAggregationDocument2 as adopted, Aggregation Documents, but is legal in Archive Documents.
Rationale
1. Our charter speaks of creating an archive format.
2. If we wish to be able to archive multiple revisions of an entry or the contents of a feed's head in a single document, we must either specify that the atom:id of a resource be repeatable within a document intended as an archive, or that we invent some other method of identifying multiple instances of the same entry or feed metadata. Multiple instances within an archive type document would be simpler.
3. Multiple versions of an entry or feed in a non-archive document is unprecedented in syndication formats. In spite of the fact that changing feed metadata after an entry is published breaks the connection between the state of the feed metadata at the time of publishing the entry and the entry, this is how feeds have always worked, so no exception to the one-feed-instance-per-document rule need be made for Aggregation Documents--that is a special case reserved only for archiving.
See http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more.
