Roy T. Fielding wrote:
> a proposal on making the feed element recursive
Equivalent proposals have often been made in the past (sometimes by
me!). These proposals fall in the category that we've come to know as "Feed
of Feeds". Each time the proposal has been made, it has been rejected. This
explains why "head in entry" is necessary -- since we can't have a "Feed of
Feeds", we need an alternative mechanism for associating Feed metadata with
entries that have been copied from other feeds.
The primary arguments against "Feed of Feeds" have been (my
apologies if I forgot some...)
1. Fear that an arbitrarily deep nesting of feeds might result in
excessively large feeds. (i.e. Feed of Feeds of Feeds of Feeds...)
2. Belief that a need to handle nested feeds would increase
complexity for client developers. With HeadInEntry, clients are not required
to understand the sourcing issues, but have the necessary data available if
they wish to use it.
3. Desire to simplify the migration path from RSS and Atom 0.3 to
Atom V1.0. The introduction of "Feed of Feeds" would result in a drastic
change in the structure of feeds that might require significant
modifications to the design of existing clients and thus tend to retard
efforts to move to the new format. While we should be completely open to
such drastic structural changes, we should only accept such changes if the
benefits of doing so are clear, compelling and overweigh the costs of
migration.
4. Questions concerning attribution in interfaces. If an entry is
extracted from a feed nested within another feed, then to which feed should
the entry be associated in an interface? Or, should the interface attempt to
show the full "path" of the nesting hierarchy that contains the entry? With
"Head in Entry" it is likely that people will say that an entry "belongs" to
whatever feed it was found in. However, with "Feed of Feeds" it is more
likely that client developers and users will seek to associate the entry
with its source feed. (Note: This is a psychological or social issue, not a
technical one.)
5. Issues concerning partially nested feeds. For instance, one may
wish to incorporate a single entry from a feed into another feed. If the
approach is to simply nest the source feed, can a partial feed be nested? If
so, what feed metadata should be maintained in the nested feed?
6. Concern that "Feed of Feeds" really doesn't buy you much that
Head In Entry doesn't already provide in the normal case. One advantage
provided by Feed of Feeds is that feed metadata would not be repeated in the
case of multiple entries from a single feed being incorporated into another.
However, this may not be the normal case. The requirement for "feed of
feeds" is primarily driven by searching and matching engines and other entry
aggregators that tend not to experience enough locality of reference in
their results to have large numbers of results from a single feed. In this
case, the occasional repetition of feed meta data in <head/> elements is
probably acceptable.
I may have forgotten some of the arguments, but this should provide
a good refresher and/or catch-up on the basic issues...
bob wyman
