Bob Wyman wrote:
Roy T. Fielding wrote:
a proposal on making the feed element recursive
(Speaking for myself, I'm not clued-up enough to understand the problem / use-case Roy's pace solves)
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".
Agreed. I'm still none the wiser as to alternatives of handling Feed of Feed type scenarios. Using an entry element to describe a feed inside a feels rather hackish. Using an OPML/OML document feels like using two distinct vocabularies where one should do.
My intention is to create an Atom-enabled "space" that is navigatable. Resources are Atom Entries, Collections of resources are Atom Feeds. From a starting point of an Atom Entry, I would like to be able to follow a series of links to find other related or neighbourly Atom entries - something like going to the parent feed and find a sibling feed.
I find Roy's pace useful for what I want to do - have a way of expressing a collection of collections - feeds of feeds. For my purposes I can definitely live with one level of recursion or nesting:
<feed> <entry>...</entry> <feed>...</feed> <entry>...</entry> </feed>
I can also live with the internal feed not having any entry elements - it will just be a pointer and metadata to another feed (presumably via a link element).
From my perspective there was a related/relevant discussion going on in the Atom Protocol mailing list a few months ago about Collections and Resources. Its easy enough to see a collection as an Atom feed, and a Resource as an Atom entry, but I can't get my head around the correct way of representing a Collection of collections without looking at either a feed inside a feed, or an OPML/OML representation for each Collection of Collections hierachy I'm expecting.
If we are going to use feeds and entries to represent collections and resources, we should at least be able to express collections of collections with the same vocabulary.
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...)
Limit the nesting to one level. (Feed inside a feed).
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.
With the above limitation the complexity would be identical to handling an entry, except the link element definitively refers to an Atom Feed rather than an Atom Entry.
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.
The additional work required is to handle a feed element at the same point as expecting an entry element. The metadata expected in the feed is roughly the same as a summary-only <entry> without the summary.
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?
The limitation above I guess disallows this particular situation.
5. Issues concerning partially nested feeds. For instance, one may wish to incorporate a single entry from a feed into another feed.
Same as 4.)
6. Concern that "Feed of Feeds" really doesn't buy you much that Head In Entry doesn't already provide in the normal case.
Just the ability to list feeds that are "filters" of the current feed. Taking del.icio.us as an example, the collection at
http://del.icio.us/tag/css would give me recent links with the css tag. I'd like to have the ability to refer to the collection
http://del.icio.us/tag/css+tutorial within that feed since it is a related feed - a more refined filter than the current feed. I'd also like to be able to link the other way - in the /tag/css+tutorial collection be able to refer to the "parent" collection /tag/css and /tag/tutorial.
For me this would be a nice to have. I don't demand it. (Although recommendations of alternative approaches would be very welcome)
Just my ha'penny. Mike
(P.S. Does Roy Fielding's email domain name - gbiv.com have anything to do with the colours of the Rainbow, as in roygbiv [Red Orange Yellow Green Blue Indigo Violet])?
