Hi Mo-
On Thu, Oct 15, 2009 at 6:29 AM, Mo McRoberts <[email protected]> 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. > Have you looked at the inline[1] and hierarchy[2] ID's? It would at least be useful to see if those would do what you need. [1] http://tools.ietf.org/html/draft-mehta-atom-inline-01 [2] http://tools.ietf.org/html/draft-divilly-atom-hierarchy-03 > 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, > > > Mo. > > -- > mo mcroberts > http://nevali.net > iChat: [email protected] Jabber/GTalk: [email protected] Twitter: @nevali > > Run Leopard or Snow Leopard? Set Quick Look free with DropLook - > http://labs.jazzio.com/DropLook/ > > > > > > > > >
