Close this search box.

Microformats in Plone

Microformats are a standard which gets adopted more and more. Many modern social networking sites support it and many projects around these such as the Data Portability Group look at them as potential standards for exchanging information.

I posted yesterday already about the XFN microformat. But there are more, here a short list:

  • hCard for marking up profile information such as name, homepage url etc. Basically it maps the vcard standard to HTML markup.
  • hCalendar for marking up events. This basically maps iCalendar fields to HTML markup and thus is useful for marking up events.
  • rel-tag for marking up tags (used in e.g. Technorati tags)
  • rel-license for marking up the license used for content

A complete list can be found in the Microformats wiki.

There are some good reasons to use microformats, such as

  • only user-visible data is exported because Microformats are marked up inside HTML code. So a user is not surprised that some additional information is suddenly available as e.g. FOAF does it.
  • It’s not just some arbitrary XML but a standard and as adoption progresses it makes more and more sense to use it.

There is of course also some reason against it, mainly that it pollutes the HTML class namespace and might conflict with CSS class definitions (as it actually happens in Plone). Still, as microformats seem to get popular it makes sense to support them.

How to use Microformats in Plone?

Some ideas come to mind and something even has been implemented already. So here’s a list:

  • categories marked up with rel-tag. These are the links appearing under „Filed under“ in the document head where the keywords are displayed. This already includes an rel="tag" attribute but the problem is the link in the href. It’s an URL pointing to the search page with a parameter to search for that keyword. The problem is that the rel-tag microformat does not allow the tag to be a parameter, it needs to be the last part in the URL path, e.g. /categories/mytag. This might need to be fixed, e.g. via some view which eats the path and returns the search results or some traversal adapter.
  • Events marked up with hCalendar. Here the problem is that there’s already a class „vcard“ around the event box. „vcard“ though is the class identifying a hCard block. Not sure what parsers will make out of „vcard vevent“ or if this simply can be changed. If people use the vcard class for styling they might have a problem. I started to mark up the events portlet though with hCalendar and there is a branch here.
  • Author information can be marked up as (very basic) hCard, as it includes a name and a URL which should be enough. Later on when profiles might become richer these are also candidates for hCard.
  • News could be marked up as hAtom. Usually the news page of a Plone site has it’s RSS feed already so that it might not be that necessary but it cannot hurt either. That way even if you don’t have an RSS feed some parsers can use this information.

There is possible more we can add, just check the list of microformats. Theoretically it would also make sense to mark up links but I never know how people actually use the Link content type. It would also make more sense once we have some basic social networking layer in place because then you can use XFN to markup links to friends (blogroll) and to your own profile pages.

How to get microformats into Plone

As said, some stuff is already done but might be enhanced and I started microformats support for the events portlet. I will certainly add hCard support to the author information later and write a PLIP on all this.

The open question is right now how to deal with the „vcard“ class in the events page and how to fix the tag-markup in the category viewlet. Any hints are of course welcome.

Having Microformats in Plone would also help with the Web Services story as not much else needs to be done if you simply want to retrieve e.g. a list of events as long as the search result is marked up with microformats. This brings me to the idea that maybe each content type should also represent a view for search results to support such things. If no view is found the default implementation could be used.

Anybody who wants to help is highly welcome!

Technorati Tags: , , , ,

Teile diesen Beitrag