XOXO versus Atom versus XBEL for Web feed lists?

Very useful response to my quest for XOXO understanding. Wow. In fact, I've had so much good discussion here and on the #atom IRC that I'm not sure where to start.

I'll start with what my current leaning is, after all that discussion. I think I want to use XBEL for managing my bookmarks, and I'll advocate the necessary extensions, and hope they are as well received as XBEL itself has been.

On to my general thoughts.

XOXO. I was pointed to a thread in which my use of rel="webfeed" was rightly deprecated. I was just grasping for something appropriate in XHTML space, and I don't think there really is. I got into an argument about whether type="application/atom+xml" is the way to go, and I'm still not fully convinced it is. The way it works for me to think about it is that for each item I have zero or more links I want to consider human-readable content links, and zero or more I want to consider feed links. It's my arbitrary decision how to decide which is which, but media type alone doesn't tell the tale. As an example, what if someone has a Weblog that is served as custom XML with XSLT to render it in my browser. The media type would be application/xml and yet it would be a content link. I see the weakness in my own argument: after all, a user agent can also make an Atom document nicely rendered for a human reader, so the distinction I'm trying to make might be an impossible one regardless of method. Maybe I'll have to cave in to the "use type" argument. I'll try it out in this entry.

So back to my first format example for XOXO. If I throw in examples of "folders", I come up with:

<ol class="xoxo">
            Weblog home
            Weblog feed
              <dd>That good ole Weblog</dd>

Umm. That's a round mouthful of tags. I'm not sure I really want to have to squint at that. I also don't like how <description>...</description> becomes <dl><dt>description</dt><dd>...</dd></dl>. That's too much markup indirection for me. Even worse that the usual reduction ad absurdum of <element name="description">....

Atom. Aristotle and then Mark suggested using Atom for Web feed list exchange. It's one of those "DUH!" moments. I can't believe it didn't occur to me. The main problem I have with Atom is that is really only offers one level of hierarchy: feed/entry. My Web feed list is hierarchical. The ready solution is to use categories to simulate hierarchies.

  <title>Example Weblog</title>
  <link rel="self" href="http://example.com/weblog/" type="text/html">Weblog home</link>
  <link rel="alternate" href="http://example.com/weblog/atom" type="application/atom+xml">Weblog feed</link>
  <summary>That good ole Weblog</summary>
  <category term="Technology"/>

I'd also need some way to separately express the hierarchy of categories. I might also have to use use the ranking extension (see for example this article) to preserve item order, if I care about it. I don't know. This looks a bit of a stretch. It certainly wouldn't be very friendly to edit by hand. The fact that the updated element is mandated, for one thing, tends to color Atom into a machine-generated-only lines. This is OK for a lot of Atom's use cases, but I think it's a real bummer for my present one.

XBEL. XBEL is just the little XML format engine that could. Despite its great age and recent neglect, it's possibly the most widely deployed of these options, because of its use in Browser bookmark formats. Not that I think that's any reason for preferring XBEL. I do like how it looks, though:

  <bookmark href="http://example.com/weblog/">
    <title>Example Weblog</title>
      <metadata owner="webfeed">
        <link href="http://example.com/weblog/atom" type="application/atom+xml"/>
        <description>That good ole Weblog</description>

Even with the required info/metadata layer, it's much cleaner than the other two options. I think that we could at least get into XBEL 1.1 native elements for alternate links and for bookmark descriptions (which I think were already proposed by others), so we could perhaps eliminate the info/metadata layer in XBEL 1.1. Regardless, I think I'll manage things for myself in XBEL as above and just use XSLT to convert to whatever starts t emerge as a viable option for export to other tools (or as a way to export to OPML if I have to).

[Uche Ogbuji]

via Copia