To keep the discussion going, I created an example of what I think a hierarchic subscription file in OPML might look like.
http://www.rssboard.org/files/myHierarchicSubscriptions.opml
Now, if you have an aggregator that supports categories, does this work for you?
Note that it's a multi-level hierarchy, not limited to two levels. Is that a problem?
BTW, there's no guarantee that non-hierarchic aggregators can understand this, and this is for discussion only, do not deploy, and all other caveats.
Hi Dave
Looks clean, simple,and sufficient, as is your habit.
Thanks as always for yourcontinued "good enufand easy to code"plumbing efforts.
stan
Looks fine and imports into Vox Lite no problem.
Steve
You should avoid nesting the outline elements, otherwise you make XSLT processing alot more difficult.
Cybarber
Imports just fine into FeedDemon...
Just saw your note on using robots.txt to host the pointer to the OPML file(s). I like it better than creating new root-folder clutter, but I'd still cast my vote (if I had one) for putting the pointer in a LINK in any ol' page, and let aggregators and spiders find them wherever they are.
Yep, it means more of a strain on servers and crawlers, fetching big HTML pages just to find a single LINK tag, but consider the advantages for content creators: on multi-blog sites like Salon Blogs and, say, the NYU Journalism School (and Harvard Law...), content autthors aren't beholden to their site's "blogmaster" to get their feeds listed in a sitewide file. People whose blogs sit in subdirectories on large sites where other, non-blog things happen on the homepage, aren't beholden to the webmaster to get the OPML published in the site root, and so on.
The pointer-in-the-server-root approach assumes the people generating RSS feeds have sway over the people and the software in charge of the server root. That's not an assumption I'd put my money behind.
Also--another good reason to put the pointer in as a LINK in the HTML is that it'll make it easy for web browsers to harvest OPML along with RSS and hand it off to an aggregator. It would enable all sorts of interesting tools and gadgets: imagine a floating window that shows you the available subscription services offered by whatever site or page you're looking at, and another that gave you a collapsable view of the site's RSS feeds, and you could click on one to subscribe to it or send it over to your PDA or add it to your blogroll, or...
Steve, when Jeremy Zawodny decided he wanted to come up with a new format for aggregators to support, I took another look at this whole thing, and realized I was just doing it to help him, and had been dragged into another pointless flamewar, so I asked myself if I really care, and realized I don't. I'm not sure he has a real use-case, or one that's concrete enough to make software for, and I don't see any buy-in from aggregator developers (please correct this if it's wrong) so I see a long road ahead for him (unless Yahoo has an aggregator of its own) and I've been through these flamewars before, and it's only worth doing if you really believe in something, and well, I don't.
So for now, RSD works great. I may just withdraw the proposal for myPublicFeeds.opml.
However, I want to make the move to hierarchic OPML files, lots of people are waiting for this.
Confusing? If so, sorry.
Still diggin.
Dave:
This you call a flamewar?
If you'd like to think it's a flamewar, that's your business. Me, I think the point of a feedback loop is to, you know, offer feedback. In any case if it makes you feel better, I'm all for hierarchical OPML files.
But now that you mention it, even cooler than hierarchical (from a flexibility standpoint at the expense of easy construction, big surprise) would be many-to-many categorization: a hierarchy of buckets followed by the flat list of feeds, each labeled with the bucket(s) it goes in. Which is probably not simple enough to pass the KISS test. So forget I said it.
One more possible point against a fixed URI for site-level OPML files: it makes it a pain to offer custom OPML for different visitors, since you'd have to hack webserver configs to get one to execute a script or whatever with a .opml file extension. You don't change your robots.txt for different visitors, nor do you change your the site icon file for different visitors. But you might reasonably want to feed different OPML to different visitors, no?
This is not a flamewar, what happened on the Syndication list, as usual, was. About three people dominate that list, and make life miserable for anyone who doesn't do things their way. In this case that meant not using OPML. To me that was a deal-stopper, so I stopped arguing. Over here the comments have been respectful and productive, even though there's been plenty of disagreement.
I saw the comment on using the robots.txt file for discovery. This solution as well as requiring a special directory or specifying a specific file at the site's root directory is problematic for ISP's and their customers. An ISP supports multiple users. An ISP don't want to add additional stuff to their robots.txt file nor add any new files in their site's root directory. Individual users do not have permissions to modify files in the root directory of their ISP for security reasons. So if I'm an ISP user with multiple feeds and I wish to provide a syndication list then how do I accomplish that?
My suggestion is to have an optional linking element in the RSS document, at the channel level, that points to the subscription list in either OPML or RSS form. This way when a person enters a new subscription into their RSS aggregator the RSS aggregator can grab the link, if present, and then present a list of additional things to subscribe to. RSS document creators could provide the new element in each RSS feed on their site. It's just another standard channel element that's always fixed to point to the subscription list.
You should note that if you don't wish to consider hierarchies as part of the solution then an RSS document that lists the feeds on your site, as items, would be fine. People could subscribe to the subscription RSS feed to learn of new announcements. I'm providing that RSS document on my Intranet so others in my organization can be notified of new feeds as we add them. This technique would allow you to categorize the individual feeds with the RSS category element. Using an RSS document to provide a subscription list works today without any changes to RSS aggregators or tools. Obviously, this solution doesn't provide hierarchy but hierarchies could be handled by using the domain attribute on the existing category element.
I'm not totally opposed to using OPML for this but am wondering why nobody thought to use RSS to do this?
As Steve suggests, the RDF format already provides a means to do it. It'd be a trivial matter to publish a flat list of the feeds and then include structuring that grouped them WITHOUT the added bulk of duplicating feeds URL again and again.
I've made an example here:www.syndic8.com
It even validates: www.w3.org
The grouping and element names I'm using are completely made up. But it does serve to demonstrate how to do what you're asking with absolutely nothing 'reinvented'.
myRadio has been creating subscription files is this exact format since February
it's called mySubscriptionsMyRadio.opml, and will be in the gems folder of any myRadio user
radio.weblogs.com
fyimikel
Hello Everyone, Just a quick question, as my google searches for this issue turned up with nothing that represents the idea I had in mind; Do you know of any ways that people are using to implement 'sub-feeds' into their feeds? Here's a quick example of what I mean. Say, I want to implement comments into my RSS feed. Firstly, I could go around and use the <comments> element. This is okay, and my feed allready uses these elements, but it's not what I want. I would still have to go to a webpage and display the comments in a layout that is not standardized. Also, i wouldn't be notified if there were new comments (imho one BIG advantage of RSS). So this is, for what I want, out of the question. Now I could go around and put them in the description of every item, like Joi Ito does with his 'full blown rss feed with comments', but that has two big disadvantages.-My feed's output is going to be HUGE if i'm going to be outputting every comment to every item.-Users with aggregrators which display every item fully in a list on one page, will have to read through every item WITH comments, making reading multiple items very irritating. I could also make separate feeds with the last comments, which users can subscribe to. Now this is good if you're sitting behind your PC all day and have a good memory of what the discussions on various items on a blog was about, but you'd easily lose track of these comments and you would never be able to see which comments belong to which item. So this is out of the question as well. Now, what I would like to do is implement a sort of 'sub-feed' to each item of my rss-feed. I want to be able to link from an item to another RSS-feed, and I want my aggregator to automatically recognize this feed and provide the user with an option to click this feed from the aggregator so it is opened and displays all the items (comments) in this feed. Now is my question, are there allready people that you know of that are extending RSS to do such a thing? If not, then my solution would be something like: <subFeed url=vandedonk.nl name="Comments" numItems="15" /> Then my aggregator could display a link like "Comments (15)" which links to AND aggregates the comments automatically when I click it. This has the advantage that if I can use the same element for linking to feeds with trackbacks, relevant links etc etc. I hope you can spare the time to help me with this issue :) Greets and thanks in advance,Sander van de Donk
I just posted an RFC about this today.
I agree totally with Stan, IMO it _has_ to be hierarchic and support many levels to be intreresting.
A bit off-topic, but I did a little activerenderer-style rendering script to present the OPML as HTML:
www.solvare.com
Shrook already uses this exact format for import and export, and has no problem with multilevel hierarchies.
