[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Don't mess with HeadInEntry!
On Friday, February 4, 2005, at 01:29 AM, Bob Wyman wrote:
4. We've been talking about HeadInEntry ever since I proposed it
back in June at the Atom Community meeting. On numerous occasions, the
as a whole has rejected the various "feed of feed" proposals as overly
complex and unnecessary. It is a bit bizarre to see all this being
in a rush as we drive towards a Last Call.
It seems to me that the main reason for the objections to "feed of
feeds" was that it seemed to open the way to unlimited recursion. I
too am a little surprised to see proposals for recursive feeds of
feeds--that's what sparked the idea of the Aggregation Document you've
taken such a disliking to.
6. All of the alternatives that have been proposed require drastic
and unlikely modifications to the design and architecture of readers.
stuff like adding an aggregation document!!) Such proposals are not
alternatives no matter how sweet one might find their abstractions...
I suspect that the large volume of proposed text that
PaceAggregationDocument lifted from PaceFeedRecursive made it look a
lot more drastic than it really is. In both of those proposals, the
proposed text was largely identical to what's in the current
draft--it's just been moved around and one or two little changes made.
However, there is a point to the argument that we should minimize how
much mucking around with do with things right now, so I've posted
PaceAggregationDocument2, which only proposes the changes necessary to
create an Aggregation Document.
As for HeadInEntry, the best argument I see for it if we adopt a
containment-based aggregation mechanism is that Entry Documents may
need to be able to refer to their feeds for context. I can think of
three ways to handle that:
1) A link to their feed
2) Use a one-entry Feed Document instead of an Entry Document
3) Allow HeadInEntry in Entry Documents only