I looks to me like the directionality imposed, with respect to
"current", on the "next"/"previous" link relations by APP's collection
paging is incompatible with Mark Nottingham's Feed-History-05 draft.
While "current" is the only relation that has temporal semantics built
in, being an "URI that, when dereferenced, returns a feed document
containing the most recent entries in the feed", both "next" and
"previous" get temporal semantics as well when used with APP or
Feed-History:
In the APP case we have
current
|
v
Feed #1 --next-> Feed #2 --next-> Feed #3
where Feed #1, #2, and #3 together form an APP collection.
In the Feed-History case, however, we have
current
|
v
Subscription --previous-> Archive --previous-> Archive
Feed Feed #1 Feed #2
where the Subscription Feed and the two Archive Feeds represent what
Feed-History calls an "abstract feed".
So the directionality of "next" and "previous", one being the inverse of
the other, is incompatible between APP and Feed-History. Now why is this
a problem?
Suppose a client subscribes to a feed. This feed could be an APP
collection (cf. the recent discussion about 'collection feeds versus
"subscription" feeds') and hence "next" would point to older entries. It
could, however, instead be a linked set of feed documents as per
Feed-History. In that case "next" would point to more recent entries
while "previous" would point to older, archived entries.
This looks broken to me, since a client has no way to find out which of
the two spec was being followed when creating the feed in question.
It could be fixed by simply changing the directionality of
"next"/"previous" within the APP draft.
(If you are not convinced by the above argument, read on. The remainder
of the mail tries to develop another argument why such a change is a
good thing. If you are convinced, however, you may stop now ;-)
And making the change would require two versions of the essentially same
collection (or "abstract feed" in Feed-History Lingo) to support both
specs; this is due to the constraints imposed on the order of entries
when paging an APP collection.
But by changing the directionality of "next"/"previous" in APP's
collection paging mechanism it would be possible to announce the
"current" feed as the head of an app:collection. The same collection
could then support Feed-History, too. No duplication is necessary.
I have to admit, however, that care has to be taken not to violate the
constraints imposed by both APP and Feed-History. APP requires that the
entries within a collection are ordered by atom:updated. Feed-History
requires that "the set of entries [within an Archive Document] does not
change over time."
This can be accomplished though, with at least the following two approaches:
1.) Each Feed in an APP collection contains the entries for a particular
month (or week, etc.). The "current" relation points to the current
month's feed, and updated entries are added to the feed of the month
they where updated in while the originals are archived.
current
|
v
March 2006 --previous-> February 2006 --previous-> January 2006
Here March 2006 would be the Subscription Feed (in Feed-History lingo)
whereas February and January 2006 would both be Archive Feeds. From an
APP collection paging point of view everything would be fine, the
ordering constraint being honored.
This approach has the disadvantage that different feeds may contain
dramatically different numbers of entries, though. This can be solved by
a bucket implementation, where new and updated entries can overflow into
a new bucket, which would then be the "current" feed.
current
|
v
Bucket #3 (21-23) --previous-> Bucket #2 (11-20) --previous-> Bucket #1
(entries 1-10)
This implementation would again honor the constraints imposed by both
APP and Feed History.
Of course there are implementations which fail to satisfy these
constraints -- however, it can be done and avoids publishing the same
entries only slightly reordered in two different feeds. I can't think of
a reason why such implementations should be made impossible.
Hence I urge you to change the directionality of "next"/"previous"
within the APP.
Regards,
Andreas Sewe
