[GEEK] Preliminary notes on OPML for BlogBridge
It’s really excellent that there is a move afoot to re-converge the OPML standard. We use OPML extensively in BlogBridge, both for import and export, for internal synchronization, and very soon, for the support of Reading Lists, so this is something of direct interest to us.
There’s been a lot of discussion about this in various places, notably Dave Winer’s opml.com site, and also by Nick Bradbury (see this and this) of FeedDemon (a very worthy competitor). I thought it was a good time to talk a little bit about how BlogBridge uses OPML and what our thoughts are about this question.
Up to now our modus operandi has been to be able to successfully accept OPML from any other sources we came across and as a result we had to be quite ‘liberal‘ in what we accepted; we will continue to do that, but it will of course be very nice if the OPML we generate also comply with the standard and pass approval of the validator that David Winer is working on.
It would seem that a key question is, what attributes should be part of the core standard and which ones in an application-specific namespace.
I guess everything that makes any sense at all to use for interchange between products should be in the core standard, and name spaces should be reserved for product or application specific features. I am not (by a longshot) an expert in designing XML standards, so I apologize ahead of time for any boneheaded comments.
Notice that among the standard attributes, below, we include a series of PROPOSED ones which seem to have reasonable meaning across products. These are of course simply proposals - we could as easily put them in the bb: name space if that turned out to be better.
Standard (Core) attributes
So, here are the attributes that seem to me to belong in the standard itself. Note some are marked “PROPOSED” because currently they are not in the standard, and BlogBridge would use them if they, or something like them, was included.
Attributes for Non-leaf-nodes (i.e. folders)
- text - the text name.
- icon - url to an icon to display with the folder (optional, PROPOSED)
Attributes for leaf-nodes (i.e. feeds)
- type: rss (for actual feeds), opml (for urls to another opml file),
- text - the name of the feed
- for type=rss
- xmlUrl - XML URL of a feed (i.e. Rss, Atom, etc.)
- htmlUrl - HTML URL of a feed (i.e. the actual site, if known)
- limit - a number of items or articles to tell an aggregator how manyto save (PROPOSED)
- rating - a number [range tbd] indicating some kind of a user rating. (In BlogBridge we use zero to 4) (PROPOSED, optional)
- customTitle - custom title set by user (PROPOSED, optional)
- customCreator - custom creator set by user (PROPOSED, optional)
- customDescription - custom description set by user (PROPOSED, optional)
for type=opml
xmlUrl - XML Url to another OPML file
for type=query
- xmlUrl - XML URL of a feed (i.e. Rss, Atom, etc.)
BlogBridge application-specific namespace
And then within the BlogBridge name space, we would have the following, because they don’t seem to have clear counterparts that would be useful for interop:
for type=rss
- bb:icon - a text identifier for an internal icon
- bb:readarticles - the coma-separated list of 8-hex-digit hash codes of articles (optional)
- bb:tags - list of associated tags (optional)
- bb:tagsDescription - short description of tags (optional)
- bb:tagsExtended - extended description of tags (optional)
for type=query
- bb:query - string representation of a feed query
- bb:queryType - type of a query (BB-specific query ID)
- bb:queryParam - parameter for the query
- bb:XML URL to extract data out of BB (optional)
Technorati Tags: aggregators, OPML
What I mostly miss in OPML standard today is the ability to export/import read/unread items.
As I see it, the main reason to use OPML is to move from one aggregator to another. When you do this, you probably want to maintain the list of unread messages.
It would be great is OPML supported it.
Comment by splintor — November 20, 2005 @ 12:27 am
Nice work, Pito - thanks for sharing this. I have to admit, though, that I wouldn’t want to see the proposed attributes added to OPML. I’d prefer to keep OPML itself simple, and create separate namespaces for additional data,
Of your extensions, I think ‘rating’ is the most useful from an attention perspective. One small recommendation: if an attribute is user-defined, add the word ‘user’ to its name (ex: ‘userRating’ instead of ‘rating’).
Comment by Nick Bradbury — November 21, 2005 @ 1:44 pm
I posted a reply to your comment, which is actually a question…
Are there any attributes that FeedDemon (or Newsgator or any other aggregator uses) which seems to be of general use?
Maybe I misunderstand the concept, but my reasoning for suggesting adding something like “CustomTitle” as a core attribute is that it seems to be more or less universally useful. And if it is, and we want to interoperate it seems like an attribute should be in the core set.
This may be a misunderstanding on my part. Would you expect application-specific attributes (e.g. feeddemon:xxx) to be interpreted/saved/restored by other apps, or would that only be true of core attributes?
I could imaging that the answer is, keep the core attributes minimal (i.e. what they are today) and have an extension name space that is NOT app specific but just a more or less agreed upon set of extensions. In that model, one might agree to have a name space called user: for user extensions to core opml, with things like:
user:rating
user:title
user:author
etc. So in that way, it is not cluttering up the core OPML but at the same time it is in some sense broader than any one application.
Is that more appropriate? Or would your preference be to simply have a tiny core set of attributes and have everything beyond that be in application-specific name spaces?
Comment by Pito Salas — November 22, 2005 @ 12:38 pm
In general I think it’s a tough sell to get attributes added to the core OPML, which is why I’ve focused more on namespaced attributes. I definitely like your idea of a namespace for attributes that could be shared among aggregators.
I’m in the process of revamping FeedDemon’s OPML so I haven’t documented these elsewhere, but as of this writing, here are some of FeedDemon’s custom attributes that could be useful to other apps:
fd:numUnread
fd:numFlagged
fd:numPostsEverFlagged
fd:numVisits
fd:firstPostDate
fd:lastPostDate
fd:autoUpdateFrequency
fd:autoPurgeMaxItems
fd:attentionRank
I would expect application-specific attributes to be discarded by other apps, but core-attributes would be retained.
BTW, my understanding (which may be wrong) is that ‘title’ is the actual title of the feed, whereas ‘text’ could be the user-defined title. Also, according to http://www.opml.org/guidelinesForValidation OPML has a ‘category’ attribute that appears to do what ‘bb:tags’ does.
Comment by Nick Bradbury — November 22, 2005 @ 2:00 pm