Mark Nottingham wrote:
Andreas Sewe wrote:
But it would be desirable, IMHO, to be able to link to archived, older
versions of a complete feed from within the current complete feed
document.
Say, a feed document contains this month's Top Ten. Wouldn't it be
nice if the feed document could link to September's Top Ten, in case
anybody is interested in all the recent Top Ten lists? And linking to
archived feed documents is precisely what "prev-archive" and
"next-archive" are for. So why can't I use them in conjunction with
complete feeds?
I think you're trying to reconstruct a different dimension; archived
feeds, when reconstructed, contain only entries that are currently
considered members of the feed; what you want to do is to have snapshots
of the feed's members over time, separate from what the current members
are.
Right. The point is that for non-complete feeds members are only ever
added (never removed) as time goes by. Hence you can reconstruct a
previous revision of an Archived Feed simply by following the
"prev-archive" links far enough into the past; so there is, for
non-complete Archived Feeds, no real need for another link relation to
cover this dimension:
This might work as a "prev-version" link relation...
Now there are already "previous" and "prev-archive"; do we really need
"prev-version" to cover the case of Complete Feeds? At least for
non-complete Archived Feeds it is not really needed, which gives me the
gut feeling that "prev-version" might not be needed for Complete Feeds
either. (Unfortunately, I cannot come up with a satisfactory definition
for "prev-archive" that would work for both cases, complete and
non-complete. But that does not mean there is none...)
(For the moment, the "related" link relation with an explanatory @title
will do.)
I am aware, now, that this is not what the current draft says, since
the three types of feed (complete, paged, and archived feed) can't be
combined in *any* way, even though the draft's introduction claims
that "[t]hese types are complementary". But at least some of the
additional expressiveness offered by the combination of complete with
either paged or archive feeds would be nice to have -- even though it
adds some minor complexities.
My gut feeling is that while there might be some use cases for this sort
of thing, it's going beyond the 80/20 point, and adding a lot of
complexity/abstraction. When I said that they were complementary, I
meant that together, they cover most feeds in common use today, not that
they can be used together.
I see. Maybe it would be a good idea to spell this out explicitly in the
spec, even if the "Completeness is defined as having all of the entries
in one physical document" condition implies it. That way you can be sure
that everyone, me included, gets the semantics right. (FWIW, nothing
prevents stable logical feeds from being both Archived and Paged Feeds,
right? Only unstable feeds can just be Paged, not Archived.)
I do want to address the combination issue, however. I'm inclined to
just state that the semantics of feeds that have more than one type is
undefined by this spec. Does that work for you?
It does. It would be worthwhile, however, to state that a future
revision of your spec might choose to define behavior for these cases.
(None of the features I have proposed would contradict the current
semantics of Complete, Paged, and Archived Feeds.)
Regards,
Andreas Sewe
