Sharing Bookmarks and Feed Lists with XML

I'm working on a programming project that requires an XML format to represent bookmarks and other collections of URIs, but before I reinvent the wheel I'd like to see if there's an existing format that meets my goals. The format should be able to hold all of the following information:

Bookmarks in web browsers
Links in web directories like the Open Directory Project
Feeds in an OPML subscription list
Social bookmarks in Delicious

There are several potential formats that could be put to use: XBEL, the outline formats OPML and XOXO and the syndication formats RSS and Atom. Each has drawbacks, as I'll go over in upcoming posts here on Workbench.

I'm starting with XBEL, because that's the best-supported format specifically designed to hold bookmarks. XBEL was created in 1998 by members of the Python community led by Fred L. Drake Jr. XBEL 1.0 continues to be the only release, though there's occasional talk on the XBEL-Specs mailing list about developing a new version.

XBEL was designed to represent browser bookmarks and has become the native format for storing them in the Konqueror and Galeon browsers. There are add-ons that extend XBEL support to more popular browsers -- one example is SyncPlaces, a Firefox add-on that can manually import and export XBEL bookmarks.

Here's what a bookmark looks like in XBEL data produced by SyncPlaces:

<bookmark id="row123" added="2008-11-25T17:30:22.352" modified="2008-11-25T17:30:22.522" href="https://workbench.cadenhead.org/">
  <title>Workbench</title>
  <info>
    <metadata owner="Mozilla" dateadded="1227634222352963" lastmodified="1227634222522963"/>
  </info>
  <desc>Rogers Cadenhead's personal weblog</desc>
</bookmark>

Bookmarks in XBEL can be grouped into folders, which themselves can contain more folders to create a hierarchy. The format's well-designed and can be extended by namespaces or the metadata element, which in the preceding example carries Firefox-specific information.

There are several drawbacks to using XBEL. The format predates social bookmarking and lacks support for tagging bookmarks or assigning them to categories like the ones employed by the Open Directory Project.

XBEL also predates the popularity of syndication, so there's no way to identify that bookmarks are RSS or Atom feeds. You also can't establish a relationship between a web site's home page and its feed. A few years ago on XBEL-Specs I floated the idea of adding type and rel attributes to bookmarks that function like they do in Atom, which would be all that's required to publish blogrolls and feed subscription lists with the format.

XBEL can't be used for web directories, feed lists or social bookmarks without extending the format. I think all three are strong enough use cases to be part of a bookmark format's core set of elements. If I choose XBEL, most of my project's functionality won't be supported by today's XBEL tools or client libraries, which is the primary reason to adopt an existing format.

Programming · Xml · 2008/11/25 · 4 COMMENTS · Link

Comments

I linked this post on XBEL-Specs to see whether I'm missing any ways it could be used for this project.

#1 · Rogers Cadenhead · 2008/11/25

If the format is extendable with namespaces, then why not simply use the Atom type and rel attributes if you like them? Similarly for other things you want, there's standard namespaces for them all, most likely.

If it supports namespaces, you should feel free to use them. "Our format support namespaces but you should never use them because somebody somewhere may have written a parser than does something stupid with them" is just not something I'd spend a lot of time worrying about unless you have a really good reason. In my book, that's no different than not supporting namespaces.

#2 · Jeremy Bowers · 2008/11/25

I may end up going that direction, but what do I gain if all the compelling functionality is in a new namespace and the namespace only works with XBEL? Particularly if I make it a hodgepodge of namespace elements from Atom and elsewhere?

One thing I've found with the RSS Profile, which encourages RSS publishers to employ useful elements from several namespaces, is that developers can be a hard sell on adopting namespaces.

If XBEL got me 90 percent of the way there already, a namespace would be the best solution. But here, three of the four features I need aren't in the format.

#3 · Rogers Cadenhead · 2008/11/25

Yeah, I sort of blipped over some of the argument. The rest goes something like: You haven't made the other posts yet, but logically, none of them are good enough for you to say "OK, I'll take this one". All of them are XML formats that accept namespaces (with one level of support or another), so I wouldn't be surprised in the end there isn't much advantage to any of them and you'll need to add namespaced elements to any of them. Given that, I'd tend to guess the ones designed for bookmarks themselves are the most likely to be meaningfully processed by other tools.

While reading that prose it sounds like an attempt at an answer, that's meant as just thoughts on the format, which I suspect you already have thought or you wouldn't be posting. I'm probably just reinforcing what you've thought.

And... yes, I'm apparently far more willing to add namespaced elements to things (as long as it degrades gracefully) than most developers, who treat it as some sort of violation of sacrament or something. Maybe I'm on one extreme (though it hasn't bitten me yet), but I think that being borderline fearful of adding namespaced elements is also an extreme.

I also can't help but notice that few developers really get the XML namespacing thing, which I strongly suspect plays into that. I do a lot of work with XMPP, and it sort of looks like it uses namespaces properly, except that when you dig into it, the standards writers don't quite get it right... and it's better than most uses. This may be connected to my willingness to use it.

#4 · Jeremy Bowers · 2008/11/26