Re: atom:feedset proposal

[Peter Keane <[e-mail]>]

Hi Mo-


On Thu, Oct 15, 2009 at 6:29 AM, Mo McRoberts <[e-mail]> 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: [e-mail]  Jabber/GTalk: [e-mail]  Twitter: @nevali
>
> Run Leopard or Snow Leopard? Set Quick Look free with DropLook -
> http://labs.jazzio.com/DropLook/
>
>
>
>
>
>
>
>
>