On Thu, Oct 15, 2009 at 6:29 AM, Mo McRoberts
<mo@xxxxxxxxxx> wrote:
On 15-Oct-2009, at 12:03, Martin Atkins wrote:
Did you consider simply making an Atom feed of items which themselves
represent feeds? Does this have any disadvantages over the new feedset
element you've defined?
I did; and indeed that’s the initial approach that I took.
However, doing so presented two key difficulties:
1. No grouping of feeds, beyond 'category'. While categories are useful, they’re a poor fit for representing a hierarchy of nodes (including the expansion state of the tree).
I'm not so sure that category is not a perfectly good way to represent extension state (at least I use atom:category in similar ways -- I know others disagree w/ that approach, though).
2. More importantly, though, in order to include the full range of hint information, one has to overload atom:entry to include all of the children of atom:feed; moreover, if you wish to provide one or more “initial” (i.e., hint/advisory/cached) entries, you need to further complicate matters by embedding sub-entries within the parent.
Thus, I switched tack to defining an atom:feedset and atom:group, which appeared to offer a couple of key benefits over the above. Most poignantly, the semantic meaning and syntax of atom:feed and atom:entry are essentially completely unchanged—they’re merely interpreted in a slightly different context when they appear within an atom:feedset. Further, having a different root element makes light work of determining whether something is a “feed of feeds” or simply a standalone feed.
I suppose you could boil it down to aiming for the greatest flexibility with the minimal impact. As atom:feedset can only occur as the root of a feedset document, the impact upon Atom Feed and Entry documents is nil. A side-effect of all of this is minimising any difficulties which might be encountered in modifying Atom document processors to work with feedsets.
It’s more of a gut feeling, but I think that in order to be *useful* in most contexts, a user agent would have to be modified to understand what the purpose of a feedset is, whichever way around it’s represented (although existing unmodified UAs would certainly be able to parse a feed where each atom:entry represents another feed, I’m not convinced that most users would have much use for a subscription to such a thing!).
Actually, I can think of many cases when I would like to subscribe to another user's set of subscriptions (although I don't necessarily think whether users might be likely "subscribe" to a feed needs to be a primary consideration when deciding whether a set should be represented by a feed).
All that said -- I like very much that you are taking a run at this issue.
best-
Peter Keane
All the best,