I haven’t written about the XOXO microformat in some time, but some recent discussions caused me to dig into my archives to source a new post.  Microformats tend to follow the rule of only formalizing the most common of existing publishing patterns (the 80-20), meaning that some more “edge case” data cannot be represented.  Does this mean that this data is useless?  Not at all: but it is outside the realm of microformats, at least for now.  So we either need to invent something new, or extend what we have.

A Page from Recent History

This is not a new problem.  Every formalised standard is going to face those who feel that their bit of metadata should be included.  Take, as an example, the RSS 2.0 spec.  Core essentials of news feeds are present: title, description, date, etc.  Lots of metadata is missing though: author name, comment counts, comment feed URLs, ane more.  People solved this problem in two very different ways: some extended, and some invented something new.

Extending RSS (or any XML format) is easy: create a namespace, add your elements, publish.  If a particular piece of metadata is popular it gets standardised in a spec’ed extension (dc:creator, slash:comments, wfw:commentRss, etc).  The benefit of this approach is that all existing parsers can still read your content.  If a parser doesn’t need your extra metadata, it can safely ignore it and present just the core content.  No new code needs to be written, and no new formats need to be learned for 80% of the applications.

There was another group interested in solving this problem: the ATOM group.  They threw away all the existing formats (RSS 2.0 and RSS 1.0/RDF) and built something brand new from scratch to accomodate their data needs.  What was the result?  Feed aggregators everywhere had to write all-new code to handle this new, incompatible, and often more complicated case.  Time and effort was wasted both in code and user education (unlearn “What is RSS” learn “What is ATOM” / “What are feeds”).  Once the standard hit a spec’ed form, what happened?  People began to use namespaces in ATOM as well, because for all the “better” it was, for some edge cases it just wasn’t “better” enough.

Back to XOXO

It seems the key is to be easily extendable, not to think of everything up front.  If microformats are going to make their way into lots of APIs and not just be used for better page scraping (Ma.gnolia does a good job of this), then extensability is necessary.  Fortunately, XOXO provides an easy solution.  Check this out:

<ul>
<li class="vcard">
<dl>
<dt>fn</dt>
<dd class="fn">Martha</dd>
<dt>Anniversary</dt>
<dd>2005-02-04</dd>
</dl>
</li>
</ul>

An hCard parser can read that.  For a normal use case, no new code is needed.  An XOXO parser can read that, and if it knows about hCard will likely know what “fn” means.  The other data is there, though.  The parser has that data.  Minimal new code, and all the data can be used.  Cool or what?

I have updated two of my DiSo plugins: Profile and ActionStream.

The profile updates mostly involve some code cleanup, a page here documenting it, and a new API to add permissions options to the permissions page.

The ActionStream update is a bit more extensive:

• Support for coComment
• Code cleanup, of course
• RSS2 output option, linked from the stream output (add &full for a different view)
• Reportedly working in WP2.5 with a patch I accepted
• Better Safari support
• If you disable showing your service usernames they are also hidden in the collapsed items
• Abitily to set permissions on updates from each service (if wp-diso-profile0.25 is installed)

About time!  I’ve mentioned multiple times that I wanted to turn the logic I use here for user photos on comments into a plugin.  I’ve made two hacks for blogger that do this, after all, why not for WordPress?

My recent work with the DiSo project has caused this interest I had to come back, in the form of two plugins.

Plugin #1 – Avatar from URL

This plugin looks at the comment author’s URL and tries to find a suitable image.  This is primarily done by looking for an hCard, but it will also use other images if no hCard I found.

Plugin #2 – AllAvatars

This plugin is what is now powering comment avatars on this blog.  It detects if you have the gravatars plugin, the avatars from URL plugin, or the favatars plugin installed and tries to use the avatar those plugins would normally give (in the listed priority order) — thus allowing more avatars to display than with any one of these plugins.

It also detects if there is photo data in the user’s profile (such as data imported by my semi-released hCard Import plugin) and overrides any other plugins with that.

Also known as Portable Social Networking, this is the concept of decentralising the social networking functionality of sites like Facebook so that one does not have to use every service to connect with everyone (previously covered here).

Videntity is a wonderful service for this movement, and one that I have been using as the hub of much of my efforts. Explode seems promising, but they’re down for upgrade.

So let’s talk about my list from last time:

1. hCards and Pingerati : For Blogger I have a wizard. Pingerati pings still manual.  For WordPress there is a widget.  Pings still manual.  For even more professional information (such as my resume) there is an hResume WordPress Plugin.  For other websites/services there is always the hCard Creator.  Of course, Videntity.org supports hCard by default.
2. XFN Friends lists : For Blogger I have a wizard.  This wizard will actually work on any web page or on any service where you can post (X)HTML (including MySpace or Xanga!)  For WordPress there is a nice plugin, although a widget version would be a bonus.  Videntity supports this by default.As far as finding/adding friends goes I have a bookmarklet for Videntity that allows one to add hCards, Facebook results, or Wink.com people results as friends/contacts.  Bookmarklets for other services would not be hard.  For Blogger we would need an actual blogroll-producing service beyond just a wizard to make this work.
3. Public/private profiles : Again, Videntity has this built right in (as long as you have the URL that the contact uses for OpenID on the friend list, it does not follow rel=me).  I am working on a solution for WordPress.  Would people be interested in a solution for Blogger/other websites?
4. Messaging : not sure where I stand on this.  Lots of nice contact options, and creating a ‘wall’-like interface on WordPress would be easy.  The question is : what is the goal of this?  If it is just the address book features then a way to integrate social networking contact lists with email clients / Gmail might be better.  If it is being able to communicate without revealing your email address a protocol/system for that might be easy enough.My brother (and avid Facebooker) says that it is about visibility.  The benefit of Facebook messaging, for him, is the unified notifications area that he KNOWS his friends all check.  He KNOWS that they will see his message.  He is not sure they check their email.

I still promote the idea of supporting rel=tag on hCards.  We need a better hCard search engine, one that takes Pingerati pings, crawls regularly (some of my pings from months ago were never indexed by the Technorati Kitchen hCard search), outputs results as hCards (to facilitate things like my bookmarklet), and recognizes rel=tag.

Perhaps a tagspace could do a rev=tag for members.  If an hCard URL has rel=tag to a page that has rev=tag to it that would give credibility to the category.

Notifications (think Facebook mini-feed) need to fit into this idea somehow.  Events are hCalendar.  Notes/posts/shares are hAtom/xFolk.  Status is something I’ve blogged about recently too.  Services like Twitter are heading in the right direction.

What’s that? Your blog platform doesn’t support XFN? You want more XOXO-centric markup on your blogroll? You want your friends marked up as hCards in the blogroll? Now you can!

This generator tool is based on the original XFN Creator and generates code for a full XOXO blogroll with XFN relationships and hCard nodes.