You can include it in your Rails app by adding this line to your test environment config file (config/environments/test.rb):

config.gem "georgebrock-assert-microformats", :source => "http://gems.github.com/", :lib => false

Now you can test your microformats using some shiny new assertions.

By default these assertions will look for microformats in Rails’ @response:

test "show view should contain an hcard" do
  get :show
  assert_mf_hcard
end

You can also test the values of microformat attributes:

assert_mf_hcard :fn => 'George Brocklehurst', :url => 'http://georgebrock.com/'

And you can pass in some HTML, which comes in handy when you’re testing view helpers or not using Rails at all:

assert_mf_hcalendar my_html, :summary => 'Birthday party'

The microformat parsing is done using Mofo, so assert-microformats supports all the microformats that Mofo supports.

If you’re interested in how it works, or you want to make any changes, the code is all on GitHub.

I’d also like to thank Tom Lea for looking over the code and making some improvements.

XFN is a microformat that expresses relationships. If a page represents you (for example your blog or your profile on a social network site) you can annotate the links on that page to indicate whether you are linking to another of your own profiles or to a friend, colleague or contact’s page.

The annotations are made using the (X)HTML rel attribute. The HTML 4 specification provides several standard values for the rel attribute include next, prev and contents. In an age of social networks, where URLs often represent people, XFN is a logical extension of this attribute.

Of course, this is open to abuse. I could add a link to this page that points to someone else’s site and uses XFN to claim that it is also my site. This is why the claims made by XFN are generally not trusted unless they are reciprocal. For example, this blog links to georgebrock.com and georgebrock.com links back to this blog. Both pages claim that the other site is about the same person, and because the claim is reciprocal it can be considered trustworthy.

XFN and rev

I’ve recently been building a social networking site, and marking up the user profiles and contact lists using a combination of hCard and XFN. While I was marking this up I found myself reaching not only for the rel attribute, but also the less common rev attribute. The rev attribute specifies the reverse relationship described by the link, for example rel="prev" is equivalent to rev="next".

This is the markup that I came up with:

 <h3>1 user wants to be your friend</h3>
 <ul>
   <li class="vcard">
     <a rev="friend" class="fn url" href="…">
       Tom Smith
     </a>
   </li>
 </ul>

 <h3>Waiting for confirmation from 1 user</h3>
 <ul>
   <li class="vcard">
     <a rel="friend" class="fn url" href="…">
       Dick Jones
     </a>
   </li>
 </ul>

 <h3>Friends with 1 user</h3>
 <ul>
   <li class="vcard">
     <a rel="friend" rev="friend" class="fn url" href="…">
       Harry Taylor
     </a>
   </li>
 </ul>

I’ve also considered using some of my own link types (with an accompanying XMDP document, of course). For example, if you have asked to be friends with someone and they haven’t yet confirmed the relationship that could be made more explicit using rel="friend" rev="unconfirmed" on your profile and inverse on their profile: rel="unconfirmed" rev="friend".

Pros and cons

There are a few things about this that I really like:

1. The markup is more semantically rich that it would be if only using rel. It expresses not only all the claims that a user has made, but also all the claims that have been made about that user, even if they are not (or not yet) reciprocal.
2. Having all the relationship information about a given user in one place makes it incredibly easy to extract very specific information with a tool like YQL or GRDDL without having to rely on specific knowledge of the page structure.

There are also a few things that I don’t like:

1. The rev attribute isn’t often used and is commonly misunderstood (although I’m not sure why, the specification is very clear on what it means). Because of the lack of understanding the microformats wiki strongly discourages the use of rev.
2. It has been suggested that using rev instead of rel for XFN link types is tantamount to creating a whole new microformat.
3. The reason reciprocal claims are trustworthy is that they are made by both of the pages involved. This markup claims reciprocation without involving the other page. While this makes sense in this specific case (the links are between profiles in the same site and are being automatically generated based on the same set of data) it would not be good in the general case to assume that just because a link has both rel and rev it is reciprocal and therefore trustworthy.

What do you think?

I’ve not previously seen the link types defined in XFN used with the rev attribute, so I’m curious what other developers, and particularly those in the microformats community think of this?

Screenshot of XFN profile discovery

Yahoo hosted another of their Open Hack events in London this weekend. I took the opportunity to play around with YQL, the Google Social Graph API and the XFN microformat and built a Greasemonkey script that recognises when you’re on a social network profile and finds other social network profiles belonging to the same person.

If you want to try it out, just follow these simple steps:

1. Get Firefox and Greasemonkey.
2. Visit this page to install the plugin: georgebrock.com/openhack2009/xfndiscovery.user.js
3. Go to a profile page (like a Twitter page, or even this blog) and you’ll see a “more user profiles” link in the rop right corner of the page

If you’re more interested in how it works, you can find the source code on GitHub.

It starts by looking for links that use rel="me" (XFN’s way of saying “this link points to another page about the same person as this page”). If it find any it uses YQL (and a clever bit of XPath magic from Brian Suda) to find more rel="me" links on those page and so on until it runs out of profile links. To make sure nothing’s been missed it’ll bundle together all of the URLs that it’s found and pass them to the Google Social Graph API. If the SG API finds any new unique URLs they are parsed with YQL too. The combination of YQL and the SG API means that the script gets good coverage for most people, whether or not they have deliberately made use of rel="me".

One fun thing about building this hack was finding my own profiles on sites that I’d forgotten about (it turns out I have a soup.io account).

A script that automatically transforms links to Technorati’s events service into a useful little menu allowing events to be downloaded or added to various online calendar services. If you want to see it action check out this live demo.

It’s a bit rough around the edges (there’s a list of issues below). It uses Dan Webb’s Sumo microformats parser to extract event details (some online calendar services don’t support iCalendar import, so the details need to be passed directly) and JQuery to manipulate the page.

Files

The latest version of the script is kept in a public repository on GitHub

How to use

1. Mark up your events using hCalendar
2. Add a link to Technorati’s events parsing service. For example, the link for this page would be http://technorati.com/events/http://blog.georgebrock.com/projects/enhanced-hcalendar-downloads
3. Add all the relevant Javascript files to your page (Sumo’s microformat.js and hcalendar.js, JQuery and enhanced-hcalendar-downloads.js)
4. That’s all you need to do, but you might want to add some CSS rules to make the menu prettier (start here: enhanced-hcalendar-downloads.css)