Responses to comments and questions about myPublicFeeds.opml.
There were lots of positive comments, people who thought that it was a good simple proposal, kudos for Jeremy Zawodny, and for OPML, etc. To all these thank you for the encouragement.
Following are responses to questions and suggestions for different approaches.
Let type be more than "rss"
Lindon Parker says the type should not be required to be RSS. This would open the door for other protocols to be used, like instant messaging, calendar reminders, etc.
I'm inclined to say no to this, because there's lots of ways to add generality but then this will become a complicated format, and hard to support. How can you say you fully support it if you must support any protocol that might come up in the future. Look at how short this spec is, that's because it leverages existing specs. No reason a format can't come along later and say it's just like myPublicFeeds.opml with some additions, relaxed rules, etc.
Why not index.opml?
I believe index.opml would be the home page for the site, in an outline, to be rendered for viewing in HTML either by a content management system, or some transformation format. Believe it or not, I actually have quite a few websites whose home pages are generated this way. (I use an outliner for more than just lists of feeds, and I'm not the only one.)
In other words this is not called index.opml because that is not what it is. Why not drop the "my" part?
I used to think it's dorky too, but users like it, and I've come to like it, mySelf. Further, it follows prior art, mySubscriptions.opml is the file all the aggregators look for to get your subscriptions from another aggregator. Why not use a link element instead?
This is the number one FAQ and I asked it myself when talking with Jeremy about this feature.
Key point: myPublicFeeds.opml is not instead of using a link element, it's in addition to a link element. Really Simple Discovery, RSD, which is a broadly supported format, works really well at answering the question -- Is there a RSS version of this HTML file?
myPublicFeeds.opml answers a different question -- "Where are all the public RSS feeds on this server?"
Think about it like this. Suppose you had 1000 RSS feeds on your server. How would you communicate that to an aggregator using a link element? What would the aggregator have to do to get the link element? Would that really be more efficient than trying to read a file that might not be there? For most servers reading a file that isn't there is more efficient than reading a 100K HTML file that might or might not contain a link element, and also might or might not be there.Why not use a text file? Or OCS? Or RDF?
If XML didn't exist, using a comma or tab-separated text file would be a good idea. But aggregators, almost by definition, are good at consuming XML, so why not use the higher level language that they all already understand?Continuing in the same vein, OPML is a good solution because most aggregators already support it, for exactly this purpose. It's easy for content producers to generate it. So it's pretty ideal.
Nothing would be gained, imho, by using RDF because aggregators don't use it for lists of feeds.
