Mgccl's Ivory Towerso tired

I'm participating in The Google Highly Open Participation Contest, I will work on Drupal because I'm one of it's users and it be nice if I can understand it's internal and work on it. Amazing for college essay xD.

This is a draft for my first task, Research Microformats and recommend ways they could be used in Drupal.
Microformats are a format based on the common XHTML. There are a few popular Microformats recommendation (I refuse to call it a standard) specifications, most notable are hCard, XFN, hCalendar and XOXO.

XFN

what is XFN

XFN are the most likely to be useful to Drupal(and the entire internet). Out going links are unavoidable part of every site, XFN is made to show the human to human relationship instead of content to content relationship of the out going link by adding rel="tag1 tag2 ... tagn".
I don't know if XFN can be extended, the background for XFN suggest there are a standard set of XFN rel tags [Friend, Acquaintance, Contact, Met, Co-worker, Colleague, Co-resident, Neighbor, Child, Parent, Sibling, Spouse, Kin, Muse, Crush, Date, Sweetheart, Me].

why is it useful for Drupal

XFN is already used by Wordpress in it's blogroll, I believe it can also be used in the same way in Drupal for these few reasons:
1. In the future, search engines might recognize XFN and map out the relationship between 2 links. Thus construct a social map of related people's sites.
2. Superfluous introduction of links to the reader. For example
<a href="http://kuzew.net:81">My colleague and friend Kuzew's site</a>
can be changed to
<a href="http://kuzew.net:81" rel="friend met colleague co-resident">kuzew's site</a>
any small javascript pop up can show up the information in the rel tag when mouse over.
3. A possibility of a module that aggregate all the links posted on the site and use the XFN information for easy browsing.
4. Map out each user's relationship

How to implement it

Outgoing links: XFN does not need to be implemented in the core because there is no core module used for creating out going links; however, it's nice to use it for modules like Links or CCK. XFN can construct it's own taxonomy group, where each one of the possible descriptions are tags.

There are suggestions to implement XFN in the core. Users can tag other users with their relationship. It's really complicated. Different user have different relationship to the same person. XFN did not say it should be in one domain to refer to another, but one node refer to another, but search engines are stupid and get confused easily, it's likely the search engine assumes a site is owned by one person, and 2 user pages link to each other does not make sense to the bots [opinion, might not be true, but this did confused me and I believe I'm smarter than bots.]. Even if the search engines are smart, mapping out the relationship between users are costly, a new table have to be provided to do the relationship linking. I don't believe most Drupal users need a social map and genealogy, that feature is best used as a contribute module.

hCard

What is hCard?

hCard is a microformats used to show profile of a person or a object.

How is it useful to Drupal?

1. hCard can be a extended part of each user's profile.
2. hCard as part of the site information

Examples

A uber basic hCard

<div id="hcard-Chao-Xu" class="vcard">
 <span class="fn">Chao Xu</span>
 <div class="org">Mgccl's Blog</div>
 <div class="adr">
  <div class="street-address">123 fake street</div>
 </div>
</div>

hCard is contained inside a div, The div id starts with "hcard", follows by the full name of the user, use hyphens instead of space. The id is not required. the class for the DIV is vcard, it shows this is a hCard that follows the vCard, it's required so parsers understand this as a hCard.
Each node's in the hCard indicates what type of information it contains. for example, fn contain the full name.
Visit the wiki to see the full specification for hCard

How to implement it

The site information can be directly built into the core, adding a few more field to the original site information page and tweak the output.
The user hCard should be a extension to the profile module, create fields(first name, last name, etc) for profile module. Then it will render the hCards inside the user profile pages. Since it creates field inside the profile module, the information on the hCard can be searched though the site.

XOXO

What is XOXO

XOXO is a outline format(not hugs and kisses), intended for describe each node of a list and allow easy rendering. The extension of the outline are done by embed definition list inside each list item.

Why is it useful for Drupal

0. Lists are more meaningful and easily aggregated in the future.
1. Book module's Outline
2. Outline of the taxonomy

How to implement it

Books module's book outline and the chapter outline can be done with XOXO. Description, url and title are 3 of the properties useful for the outline. just adding the following for each node in the list is enough

<dl>
      <dt>description</dt>
        <dd>snap some teaser or something...</dd>
</dl>

List of the taxonomy can be another application of XOXO, description of each category or tag can be embedded with XOXO. Best implemented in the core

There are no other places in the core requires XOXO, users might write posts embed XOXO, but like all other XHTML, user should not depend on core Drupal providing tools for posting, but rather write himself, use a WYSIWYG editor support microformats, or get a contributed filter with this supported.

Some simple rel attributes

What are the rel attributes

The family of rel attributes act as a simple description for links. The most famous one would be rel-nofollow, telling the search engine not to give the link any credit when ranking websites. rel-tag show the link as a tag, it has already implemented in Drupal 6. rel-license describe links connect to a license page.

Why is it useful for Drupal

1. rel-nofollow can fight spammers
2. rel-license provide information for bots

How to implement it

rel-nofollow should be part of the core for the comment module. and add a setting for global allow or disallow. Should be easy to add a rel="nofollow" condition(I assume... I don't know what handles external URLs...)
rel-license is not much useful for the core because most sites only link one license at the bottom of the page. but it should be implemented in the CCK, in case anyone uses CCK to create a download site, then each page can have a license field.

Other notes

XFN, rel-nofollow, rel-license and rel-tag all embed themselves inside the rel attribute.
rel is a attribute for a collection of relationships of the linked document to the current one. They all describe the link in some way, XFN is different from the other ones. It describes the relationships between the owners of the documents instead of the document itself.

hCalendar

What is hCalendar

hCalendar is a format to explain a event in time.

Why is it useful for Drupal

Serve as a input/output format for event and calendar CCK, some softwares can interpret them.

Examples

<div class="vevent" id="hcalendar-Owning-noobs">
  <a class="url" href="http://mgccl.com">
    <abbr class="dtstart" title="2007-12-05">December 5th</abbr>, 
    <abbr class="dtend" title="2007-12-06"> 2007</abbr>
    <span class="summary">Owning noobs</span>&mdash; at 
    <span class="location">Long Island</span>
  </a>
  <div class="description">describe the event</div>
  <div class="tags">Tags: 
    <a href="http://eventful.com/events/tags/PWNING">PWNING</a>
    <a href="http://eventful.com/events/tags/NOOB">NOOB</a>
  </div>
</div>

The div class "vevent" defines this block uses hCalendar.
Like hCard, every container for the information are declared by it;s class attribute. All class attributes are obvious what it means. For the nodes contain time, the title attribute contains the ISO8601 time format. It's much easier for computer to read than "October 13th".

How it can be implemented

Clearly, it should work with Event module. Event module will add a page to import hCalendar into database, it can be separate and not depend on any Drupal scripts. Event's output on pages should also be hCalendar, that's all the changes the module should endure. The output are XHTML for each individual event page. Create a template and replace some variable would do.
Calender CCK could do the same.
Microformats parser could help with the parsing.

Some other microformats are in draft stage, it's not recommend for Drupal. hAtom is worth a mention, hAtom embed itself on normal XHTML, enables syndication. Personally I don't like that idea, it's better to create a separate Atom, saves bandwidth.

rel is not important enough for dedicated parameter in l(). l() are for internal links, the only internal link I found would use rel is the rel-tags. l() uses drupal_attributes() to add the attributes, adding a rel flag would be over kill.