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">
<li>
<p>Technology</p>
<ol>
<li>
<ul>
<li>
Weblog home
Weblog feed
<dl>
<dt>description</dt>
<dd>That good ole Weblog</dd>
</dl>
</li>
</ul>
</li>
</ol>
</li>
</ol>
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.
<entry>
<id>http://example.com/weblog/</id>
<updated>2005-05-23T15:38:00-08:00</updated>
<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"/>
</entry>
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:
<folder>
<title>Technology</title>
<bookmark href="http://example.com/weblog/">
<title>Example Weblog</title>
<info>
<metadata owner="webfeed">
<link href="http://example.com/weblog/atom" type="application/atom+xml"/>
<description>That good ole Weblog</description>
</metadata>
</info>
</bookmark>
</folder>
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]