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 knew others were talking about distributed social networking, but Messina is working on code, and even code for WordPress! The Kilroy concept (an “I was here” plugin) looks excellent. Avatars looks like exactly what I’ve been saying I should do since I installed Gravatars on this blog. The contactlist plugin looks like basically what I have here (his code, I believe), but I’ve hacked mine some.  His delegation looks a lot like what I want to add to my XRDS plugin.  Pempeth would go great with his contact form concept.

Other cool stuff there too — overall just excited that things seem to be picking up a bit in this field — I’m writing some bookmarklets just now, and really should clean and release some of the remaining WordPress code.

Pempeth is the result of my work based on my previous private messaging TEP.  The protocol draft has matured and there are now implementations! (see the page).  Most notable is a WordPress plugin, active on this site.

The development of that plugin also sparked an XRDS plugin, which I have also released (despite its somewhat cryptic interface).

Those looking at the main page may also have noticed changes. Yes, that’s a mini-feed based on my online activity.  Yes, it’s a plugin.  The interface, however, only allows for adding sources (not editing or removing) and is somewhat cryptic, so I have not released it yet.

You can also now log into my blog with your Facebook account (see link in header)!  This uses the API, so I don’t got your Facebook password or anything like that.  Also an as-yet-unreleased plugin.

Fun days!  I’m going to be working at AideRSS as a co-op in the coming months, should be fun and more freeing than school!

A rogue plugin was eating all of your comments!  Sorry, it’s fixed now 🙂

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.