OK. I'm adding this text just after the list of feed types in the
introduction;
---8<---
The semantics of a feed that combines these types is undefined by
this specification.
--->8---
WRT what future specs can or can't do, that's pretty much up to them.
Cheers,
On 2006/10/12, at 2:42 AM, Andreas Sewe wrote:
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
--
Mark Nottingham http://www.mnot.net/
