Internet technology hosted by Berkman Center
Tuesday, October 14, 2003
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.
# Posted on 10/14/03; 8:19:57 AM -
Several notes after a full day of discussion on myPublicFeeds.opml.
1. I have implemented an experimental myPublicFeeds.opml that lists the public feeds from sites hosted at blogs.law.harvard.edu. As the comment at the top of the file clearly states, this is for experimental use only, the format and location are subject to change and may be withdrawn entirely. Do not deploy until the disclaimer comment at the head of the file disappears.
2. As I implement this on my server I wonder if it should be at the top level of the site. It would be great if there was a folder for files like this. This might be something the W3C could do for us, much like the creator codes registry that Apple maintained in the 80s (perhaps they still do, not sure). Seems like it wouldn't take much resources, just a web app. Since there have been comments relating to a W3C working group working in this area, perhaps this will be an incentive for them to come up with a quick answer. I noted that the P3P format invents a "w3c" sub-directory. That would be perfect.
2a. In Manila there's a folder called "xml" that contains most of the XML that's available for the site as a whole (there are other xmlizations that are about specific documents that are available elsewhere).
3. People want more generality, asking if we know for sure that there's going to be a successor format that can meet their needs. I have no idea, and I think it's not very likely, given how hard it is today to get people to put aside their objections and accept a "good enough" solution.
4. I don't fully understand the Yahoo scenario. I found in designing this I needed to know exactly how the aggregator user interface would work. I look to Jeremy Zawodny to fill in the details. And Yahoo hasn't, as far as I know, gotten any buy-in from aggregator developers. My guess is that they have their own aggregator in-house, but that's just a guess. I've been assuming that we don't have the HTML text around for discovery, and no easy way to know where the corresponding HTML text is, or if there is any.
5. On the other hand, no way do I want to go back to the drawing board. I think this is a very useful feature. With a content management system it's a piece of cake to implement, it took me about one hour from beginning to end. I'd love to see all hosting services provide this feature, or something very much like it.
# Posted on 10/14/03; 8:48:16 PM -