From time to time, talking with aggregator developers, the question of adding hierarchy to mySubscriptions.opml comes up. Since some aggregators support categories of feeds it would be great if they could exchange multi-level lists. And it would be great if there were instructions for aggregators that don't support categories that tell them how to interpret lists that have hierarchy. We never hear from aggregator developers, I guess they're to busy to compete with professional mail list posters, but now would be a good time for them to express an opinion.
Is this a good point to add the idea of hierarchy to subscription lists? OPML is certainly up to supporting it, after all that's what it was designed to model, editable hierarchies. I'd be happy to write the spec text for this if you tell me what to write. I'm doing a design for Yahoo, there's no reason I can't work for the aggregator developers too. I want to.
Hi,
It would be great to see this spec?d up.
Here are my thoughts...
The aggregator should parse the file looking for any occurrences of the <outline> tag. Any tag containing children should be considered a folder and any child outlines rendered within this context. Any outline with children should include an attribute ?text? which specifies the title. Any childless outline should include the attributes type, text, description and xmlUrl, where type is equal to ?rss?. Each RSS outline tag should be processed within the hierarchy context.
Duplicate RSS items should be allowed in the hierarchy as some aggregators support mapping of feeds to multiple categories.
RSS Items should be allowed at all levels of hierarchy i.e. at the root and anywhere else. I?m not too sure about this...
Aggregators that do not support hierarchy should parse the file as described above except disregard the folder hierarchy context, producing a flat list.
Steve
Steven WoodVox Lite Developer - www.stevenwood.org
Am I right in assuming that the main purpose of the hierarchies would be to support categorization?
If so, I'd strongly suggest that the hierarchies be *views* of the categorization data, rather than using a hierarchical model.
The reason being that a a particular feed might appear in many different trees (animals->cats, internet->blogging->cats). This would need either hard-to-manage duplication or probably harder-to-manage cross-linking.
Speaking as an aggregator developer, it would be helpful if there was some unambiguous way of telling that this data was a feed list rather than anything else formatted with OPML.
I agree with Steven Wood: "Any [outline] tag containing children should be considered a folder and any child outlines rendered within this context."
To Danny: no, this isn't about categorization the way you're thinking of it. Many newsreaders allow you to organize your subscriptions into groups -- much like file managers and most email apps let you organize with folders.
Our OPML import/export already supports one level of categorization/folders. I believe many aggregators already output OPML supporting this, using nested <outline> tags. So, yes, we're all for hierarchy.
BlogExpress supports multi-level categories and OPML import/export.
I would like to see OPML support hierarchies. I think this is a great idea. This hierarchy support will be a natural fit for newsfeed categories but the spec doesn't need to address this. Danny's concern about duplicate children can easily be addressed by newsreaders and the spec doesn't need to be complicated to "mitigate" this scenario.
What's best from an interface perspective? If you have to navigate a deeply nested tree to find out what feeds have updated, doesn't that somewhat defeat the purpose of RSS? If your subscriptions appear as a flat list, you can see at a glance which contain new posts. On the other hand, if you read your blogs from an aggregator/stream sort of view (as I think Dave does, and as appears here: blogs.law.harvard.edu), then it doesn't particularly matter if your OPML contains hierarchy. Nevertheless, I'd say that supporting hierarchy in OPML subscriptions will encourage hierarchy as an aggregator interface, and I'm not sure that's a great idea. --Ethan
Ethan, the choice of presentation should be up to the application developer. OPML can be neutral rather than designed to favor a particular implementation.
Brent - that is what I meant! It's one of the things I've got (half-implemented) in IdeaGraph.
What if your want a channel (or item) to appear in more than one group?
Alan - easily addressed - how so? My application's data model is digraph- rather than tree-based, so the modelling isn't a problem. The problem is getting the data in, and maintaining the relations. I can't remember much of treewalking theory, but to identify the duplicates you're going to have to do some walking (the same problem would apply using a RDBMS backend or whatever). Extra work coding, and extra work at runtime, every time a node is moved.
All I'm suggesting is a little thought up front may make life easier later.
Brent - that is what I meant! It's one of the things I've got (half-implemented) in IdeaGraph.
What if your want a channel (or item) to appear in more than one group?
Alan - easily addressed - how so? My application's data model is digraph- rather than tree-based, so the modelling isn't a problem. The problem is getting the data in, and maintaining the relations. I can't remember much of treewalking theory, but to identify the duplicates you're going to have to do some walking (the same problem would apply using a RDBMS backend or whatever). Extra work coding, and extra work at runtime, every time a node is moved.
All I'm suggesting is a little thought up front may make life easier later.
Alan, the problem is that introducing hierarchy into OPML subscription files will strongly suggest to aggregator developers that their apps need to support nesting of feeds. Therefore the debate should at least partially be about whether that's a good way to present feeds. I don't think it is, but I'd like to hear from people who feel otherwise. As one data point, Oddpost supports organizing feeds into nested folders, yet the vast majority of our users (90+%) leave them flat.
Alan, re. "...the choice of presentation should be up to the application developer." I agree entirely. I'm also saying that the choice of model should be up to the application developer as well, not dictated by the transport syntax.
(apologies for double-post just now, my IE's playing up)
Ethan, I personally think hierachies can be a very good way of presenting feeds (I use Amphetadesk this way), but if structuring the channel-list feed this way makes it harder to use other views (the tree has to be flattened before any other structure/ordering can be built), then it probably isn't a good thing.
Ethan -- the fact is that many newsreaders already support hierarchies. It can be debated whether this is a good idea or not, sure, but the point is moot.
So the question is a practical one, how to move subscriptions between different newsreaders and preserve the hierarchy. A simple solution would be to say that OPML subscription files can make use of OPML's existing support for hierarchy.
Ethan, our users would revolt if they couldn't organize feeds into folders. Hell, I'd revolt. It's not a nice-to-have in an aggregator, it's a basic necessity.
I second Brent's assertion that the point is moot.
can we nail down the whole xmlUrl vs xmlurl mess at the same time?
And yet a perfectly wonderful aggregator, Radio, has no concept of hierarchy. Point being, there is still a difference of opinion on what constitues a "basic necessity" in aggregators. However, if subscriptions opml contains hierarchy, aggregator developers will look at that and say "hey, hierarchy is critical information, I have to support it." And so you perpetuate a particular kind of interface. Dave has expressed some solid reasons for instead going with the Radio-style interface, so does it make sense to modify the format in a way that will influence current and future rss reading interfaces in a different direction? Sure, if you've decided that that's definitely the right direction to go. But it seems to me that a consensus has yet to be reached.
Both views are correct because there are two styles of aggregators out there.
1. NetNewsWire and Bloglines work one way.
2. Radio and Oddpost work the other way.
There's a fundamental difference in philosophy. I prefer, vastly, #2. In fact, I think the first approach is useless. But I respect the developers and their users, because it's provable that they exist, and as a developer of RSS, they are my users, and I feel the need if I can to help them get what they want, and this is key, without in any way limiting what Oddpost and Radio do.
We needed to have this discussion to get to this impasse so that a solution could reveal itself, and I think one has.
1. Suppose your aggregator understands feed hierarchy. In addition to putting out mySubscriptions.opml, you also put out myHierarchicalSubscriptions.opml and in that file you reflect your hierarchy. Let's leave that up to Brent et al to specify.
2. When they are asked to import subscriptions, first they look for the new file, if they find it, read it, and use the hierarchic information. If not, fall back to the current behavior.
3. Now to the sticky part. Suppose you're Radio or Oddpost, an aggregator with soul, one that says only a totally anal retentive person worries about categorizing their feeds. We have right on our side, but we have to deal with this mess that our unenlightened brothers have perpetrated. What we do is the same thing they do, favor the hierarchic list and fall bakc to the non hierarchic list, with the important difference that we preserve the hierarchy. So when we export, we export both versions, and any new feeds that are added are added to a category called New Feeds or some such (let's agree on this). That's the key step, preserving the hierarchy.
Caveat: This is not spec text. Do not implement it. Don't show it to your inner-lawyer. Etc etc.
My aggregator may not have soul, but I claim it has a better singing voice than your aggregator. So there! Neener neener.
Still working to get it to keep a steady beat,
Mister Anal Retentive
Coool. Glad you could see that my tongue was planted firmly in my cheek. ";->"
So now we are passing around a flat file and a hierarchical file (containing the same data items as the flat file, and possibly duplicate items). An 'aggregator with soul' will have to manage the import, maintainance and export of these...
I'm outta here!
Just let us know when there's a _usable_ spec, ideally using XML as it was intended.
The sign of a true gentleman is that he leaves quietly and doesn't slam the door behind him.
Here's a trial balloon for the hierarchic subscriptions file.
blogs.law.harvard.edu
As an alternative, could the hierarchy be represented by adding a simple optional attribute to each newsfeed which would be the category that if belongs to?
Interesting thought, but that limits it to two levels, and why not use OPML's ability to represent hierarchy?
Dave, Rather than using two files, how about supporting hierarchy in mySubscriptions.opml, but just throwing a caveat in the spec that says displaying the hierarchy is entirely optional? Retaining the hierarchy on export, as you said, would still be key.
