[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: atom:feedset proposal
On Thu, Oct 15, 2009 at 6:29 AM, Mo McRoberts <mo@xxxxxxxxxx>
I did; and indeed that’s the initial approach that I took.
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?
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.
All the best,