On 2006/10/10, at 6:49 AM, Andreas Sewe wrote:
Thomas Broyer wrote:
2006/10/9, Andreas Sewe:
But while the draft states that "[t]hese [feed] types are
complementary"
(section 1), but is unfortunately silent on how precisely the three
different types can be used together.
Here are a few questions I still have:
- Is it possible that an Archived Feed Document is marked as
complete?
By definition, an Archived Feed is a set of Feed Documents, and an
Archive Document is a Feed Document within that set. It cannot be
"complete", unless it is the only one in the set, and therefore
represents the whole Archived Feed as a single Feed Document. It's
"current" link should then point to itself (i.e. the same as the
"self" link).
Thank you for the clarification; I did not get my terminology
straight.
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.
This might work as a "prev-version" link relation...
- Is it possible that a Paged Feed's pages (i.e., its feed
documents)
are marked as complete?
No. By definition, a Complete Feed is a single Feed Document.
See:
2. Complete Feeds
A complete feed is a feed document that contains all of the entries
of a logical feed; any entry not actually in the feed document
SHOULD
NOT be considered to be part of that feed.
This is the same reason as to why archived feeds can't be complete.
But, as I argued above, making an archive of complete feed
documents available ought to be possible with archived feeds, too.
Now, in contrast to archived feeds, paged feeds serve a different
purpose: they allow a logical feed to be divided into more easily
digestible pages. (See the APP draft: "A naive client such as a web
spider or web browser could be overwhelmed if the response to a GET
contained every entry in the Collection, and the server would waste
large amounts of bandwidth and processing time on clients unable to
handle the response.")
And I can't think of a reason why complete feeds are per se small
enough to be served without problems as a single document. Granted,
the above Top Ten list example contains, in all likelihood, only
ten entries, but what about Top 100s, the Supercomputing Top 500,
etc.?
It isn't a complete feed, then. Completeness is defined as having all
of the entries in one physical document.
- Is it possible to serve a single, possibly large Archive
Document as
multiple pages?
Not sure what you're talking about...
>
Do you mean a Logical Feed would be split into "stable subsets", each
such subset split into "unstable" Feed Documents?
In this case, as each document is not "stable", it's a Paged Feed,
not
an Archived Feed, even if the subset of entries from within 2 Feed
Documents form a "stable subset".
If every Feed Document is "stable", then you have an Archived Feed an
dyou can link Feed Documents to each others using next-archive and
prev-archive.
This was more or less what I was getting at, and while I recognize
the issue of stability, being able to page an archive document does
make sense if you follow the above analysis: 1) archival of
complete feeds is useful (each archive document will be marked as
complete) and 2) even complete feeds may need to be paged (each
complete archive document might be served as several pages).
Putting it all together this leads to a variant of the diagram in
my previous mail:
Compl. Archive Document 1 -\ Compl. Archive
Document 2
========================= \
=========================
Page 1.1 -next-> Page 1.2 \-prev-archive-> Page 1.1 -next-> Page
1.2
Here Archive Document 1 contains, say, last month's Top 100 as a
complete archive document split into two pages of 50 entries each.
It then links, via "prev-archive", to August's Top 100 which is
again split in two.
Does this explanation make sense?
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 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?
Cheers,
--
Mark Nottingham http://www.mnot.net/
