Subject: atom:feedset proposal

From: Mo McRoberts <[email-masked]>
Date: Thu, 15 Oct 2009 09:43:59 +0100

Hi folks,

I’ve come across a requirement in the course of a project I’m working  
on for a format which is a little richer and more readily-extensible  
than OPML. Creating something Atom-based was a natural fit for my  
needs, and so that’s what I’ve done.

Although I have no particular expectations of this supplanting OPML  
for subscription exchange, I’d like to offer a draft version of this  
spec for review by the (far more knowledgeable than me) folk here.  
I’ve had good initial feedback, but it really needs a wider audience.

If there are no obvious reasons why *not*, my intention is to submit  
it as an I-D as a proposed extension to the Atom Syndication Format.  
If it turns out I’m barking up the wrong tree, it goes nowhere  
(obviously)!

The current working draft can be found at:

http://nexgenta.github.com/Baird/draft-atom-feedset.html

A couple of examples of the format can be found here:

http://github.com/nexgenta/Baird/blob/gh-pages/samples/guardian/feeds.xml
http://github.com/nexgenta/Baird/blob/gh-pages/samples/bbc/iplayer-feedset.xml

Any criticism (though I prefer the constructive kind) gratefully  
received.

Thanks,

Mo.

-- 
mo mcroberts
http://nevali.net
iChat: [email-masked]  Jabber/GTalk: [email-masked]  Twitter:  
@nevali

Run Leopard or Snow Leopard? Set Quick Look free with DropLook - http://labs.jazzio.com/DropLook/

---

From: Martin Atkins <[email-masked]>
Date: Thu, 15 Oct 2009 12:03:05 +0100

Mo McRoberts wrote:
> 
> Hi folks,
> 
> I’ve come across a requirement in the course of a project I’m working on
> for a format which is a little richer and more readily-extensible than
> OPML. Creating something Atom-based was a natural fit for my needs, and
> so that’s what I’ve done.
> 
> Although I have no particular expectations of this supplanting OPML for
> subscription exchange, I’d like to offer a draft version of this spec
> for review by the (far more knowledgeable than me) folk here. I’ve had
> good initial feedback, but it really needs a wider audience.
> 

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?

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 15 Oct 2009 12:29:26 +0100

> represent feeds? Does this have any disadvantages over the new feedset

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).

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!).

All the best,

Mo.

---

From: Peter Keane <[email-masked]>
Date: Thu, 15 Oct 2009 13:06:34 -0500

Hi Mo-

On Thu, Oct 15, 2009 at 6:29 AM, Mo McRoberts <[email-masked]> wrote:

> 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-masked]  Jabber/GTalk: [email-masked]  Twitter: @nevali
>

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 15 Oct 2009 19:39:08 +0100

Hi Peter,

Thanks for the comments.

On groups—

I don’t doubt there are mechanisms whereby a tree *can* be presented  
in terms of categories, and in all honesty I’m not hugely attached to  
the proposed atom:group. An atom:feedset containing atom:feeds, each  
of which may be categorised in a pretty rich and flexible manner could  
work just as well (if not better) and potentially be a more  
appropriate fit with Atom as a whole.

My only concern, and it’s a pretty minor one, is that quite a  
different model to that used by OPML could hinder any potential  
adoption as an alternative to it for many applications. I’m leaning  
towards that being a more hypothetical problem than anything else,  
though!

> 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).

I possibly mis-phrased that. Certainly, being able to subscribe to a  
set of feeds is useful; that’s part of the motivation for tackling  
this in the first place. *However* I don’t think the usual UI  
representations of a feed tend to be a good fit for an atom:feed where  
each atom:entry in turn represents another feed. In other words,  
whichever way you did it, you’d have to modify UAs in any case.

I had a quick read through the drafts you linked to (much appreciated).

Clearly from those, it would be possible to represent a feedset as a  
feed/entry, where each entry has a link with a relation of “down”,  
containing an ae:inline which contains initial feed metadata and  
possibly some entries. It does seem  a little like using a  
sledgehammer to crack a nut, though.

I’ll readily admit this is fairly subjective, but, it seems more  
logical to add a new container to represent a (possibly unrelated)  
collection of feeds, when the expression of “a feed” is already well- 
defined and more or less left well alone, than shoehorn this into a  
feed hierarchy. Although I can see potential applications for the  
hierarchy (i.e., situations where you would ordinarily have a feed— 
such as for a list of posts, and normally have no way of describing  
child feeds—such as a feed of comments on each post), it doesn’t seem  
to quite fit with the current feed-related uses of OPML. This isn’t to  
say it won’t -technically- fit, as it clearly will (my feedset is  
conceptually just a subset of the hierarchy when you boil it right  
down), but I’m not sure it’s “right”.

Apologies—that was a bit of a ramble. Hopefully that made sense!

All the best,

Mo.

---

From: "James Holderness" <[email-masked]>
Date: Thu, 15 Oct 2009 20:18:35 +0100

> so that’s what I’ve done.

I'm not yet sure whether I think this is a good idea in general, but if you 
really need something more than OPML, I by far prefer your proposal to the 
suggestion others are making that you somehow try and use a regular atom 
feed.

Some comments on the current draft:

1. Get your own namespace for the new elements. I'm almost positive you're 
not going to be able to extend the existing Atom namespace the way you're 
proposing, and I don't see any advantage to doing so even if you could. 
Having your own namespace doesn't stop you reusing Atom elements where 
needed.

2. In your draft spec, the group element has collapsed attribute, but in 
your example you're using an expanded attribute. I'm assuming one or the 
other is out of date.

3. The spec seems to indicate that the collapsed attribute is in the atom 
namespace. However in your example file it's in the default namespace which 
would make more sense.

4. Why restrict the author element in the feedset to no more than one? That 
may be all that is required for your needs, but you need to consider how 
others might use the format too. Given you're using Atom elements it would 
seem logical to follow Atom's lead and allow both multiple authors and 
contributors.

That's all for now.

Regards
James

---

From: Mo McRoberts <[email-masked]>
Date: Thu, 15 Oct 2009 20:30:49 +0100

Hi James,

Many thanks for taking the time to review and comment, it’s very much  
appreciated.

On 15-Oct-2009, at 20:18, James Holderness wrote:

> 1. Get your own namespace for the new elements. I'm almost positive  
> you're not going to be able to extend the existing Atom namespace  
> the way you're proposing, and I don't see any advantage to doing so  
> even if you could. Having your own namespace doesn't stop you  
> reusing Atom elements where needed.

Noted, will tweak.

> 2. In your draft spec, the group element has collapsed attribute,  
> but in your example you're using an expanded attribute. I'm assuming  
> one or the other is out of date.

Ah, example is incorrect. It should be “collapsed” (with omission  
being collapsed="no").

> 3. The spec seems to indicate that the collapsed attribute is in the  
> atom namespace. However in your example file it's in the default  
> namespace which would make more sense.

Spec’s wrong on that front.

> 4. Why restrict the author element in the feedset to no more than  
> one? That may be all that is required for your needs, but you need  
> to consider how others might use the format too. Given you're using  
> Atom elements it would seem logical to follow Atom's lead and allow  
> both multiple authors and contributors.

Spec’s wrong there, too—it was supposed to follow Atom’s lead in  
general, so I’m more than happy to defer.

I’ll revise both spec/examples later on this evening to fix the above.

All the best,

Mo.

---

From: Sam Johnston <[email-masked]>
Date: Sun, 18 Oct 2009 11:21:45 +0200

> represent feeds? Does this have any disadvantages over the new feedset

This was my first thought too - unless there was some significant
functionality that could not be replicated using e.g. categories then I
would be hesitant to complicate Atom's simple and elegant model. I'm yet to
see a compelling reason for a new entity.

Sam

---

From: "James Holderness" <[email-masked]>
Date: Sun, 18 Oct 2009 13:03:45 +0100

I was going to have a look at implementing this proposal as an import/export 
format for my feedreader this weekend, to see what issues might arise, and 
it immediately occured to me that there were a few things missing from the 
spec.

If you want people to be able to use this format as an alternative to OPML, 
I think most of the following are fairly essential.

1. A file extension for Windows users and possibly a file type code for Macs 
(not being a Mac user, I don't know how important that is).

2. A media type for browsers. I see there was a mention of MIME types in 
your table of contents, but no mention of it in the spec itself, possibly 
because the original intent was to use the Atom media type.

3. A catchy name, so websites can identify the format that they're offering 
for download and feedreaders can include an "Import From XXX" menu that will 
mean something to users.

4. An identifiable icon, both for websites offering this format for 
download, and to represent the format when you have bunch of these files 
lying about on disk.

Not that having all of the above is going to guarantee you widespread 
adoption or anything, but without these things you'll be making it a whole 
lot harder for people to use the format.

Regards
James