One of the differences between RDFa and microdata is that microdata is much more sensitive to the placement of attributes within the HTML.

For example, let's say you have a profile page about yourself and you want to add an image of yourself to the profile. In RDFa, you use the rel attribute to create the relationship between you and the picture. There are a number of places you could add this rel attribute, so long as it is in between the id for you and the <img> tag.

    <div about="lin" rel="image">
      <img src="/img/spacer.gif"> 

Because the rel attribute knows it is looking for a URL attribute, like href or src, you don't have to worry about it misunderstanding what you meant if you add a little text (or even particular extraneous HTML elements) around the picture. And you can even have multiple values included for the same rel attribute.

    <div about="lin">
      <div rel="image">
        
        <p>And here are some pictures of me.</p>
        
        <img src="/img/spacer.gif"> 

In contrast, there is only one place where you can put microdata's itemprop attribute—directly on the value's HTML element itself.

    <div itemid="lin" itemscope>
      <p>And here are some pictures of me.</p>
      <img itemprop="image" src="/img/spacer.gif"> 

What this means for Drupal

As I explained in my post about theming with HTML5 and RDFa, Field module handles most of the RDFa output on a normal site. It inserts RDFa's rel attribute (or property or rev) on the <div> that wraps around the field formatter output. Theoretically, it would work like the following:

However, this simply doesn't work for microdata. The itemprop can't be added to the wrapping <div>, it has to be placed within the field formatter's output itself.

With RDFa, Image module doesn't need to be aware of whether or not there is extra markup... the formatter just passes the element up to Field module which worries about the RDFa. However, with microdata, Image module needs to place the itemprop attribute itself.

What was once centralized in core's Field module now has to be coordinated across contrib's field formatter modules.

A little tech difference turns into a big social difference

Adding RDFa support in Drupal required much less explicit participation from module developers... it's just on by default. Because all fields pass through the code in field.module, contrib module developers didn't have to do anything in order to enable RDFa markup for their fields. In contrast, microdata will take explicit cooperation from module developers who are creating field formatters.

In some ways, the lower amount of coordination between developers that RDFa affords is a good thing. Drupal is a very large, very loosely coordinated system; as of early August, just shy of 200 Drupal 7 modules defined field formatters (out of nearly 2,000), and there will surely be many more coming. If current trends hold, it would be easy to see the number of modules defining field formatters reaching 800-1,000 before Drupal 7 module development winds down.

Explicit participation from that many developers is tough. It means there are a lot of people (hundreds of developers) who you have to teach the basics of metadata placement to.

... but more work isn't necessarily bad

On the other hand, I think that the explicit participation that microdata requires from field formatter module developers could turn out to be a good thing.

Currently, field formatter developers don't understand how their fields get marked up with RDFa... because we don't ask them to understand. While this works for basic fields, there are a couple of ways in which it can go wrong.

Uninformed field formatter developers

Most field formatter developers don't review their RDFa output and wouldn't know what to check for if they did. Some formatters do things like adding linked headings within the field value itself instead of working with labels, which can really mess up rel values.

Compound fields

Currently full RDFa output for all field data requires that field formatters be reduced to their most granular level of data. Some modules allow for this. For example, Field Collection encourages you to decompose the information in your fields into the most basic units. You can create a wide variety of complex fields using only Field Collection and the fields that core provides.

In contrast, something like AddressField doesn't rely on the entity-field relationships to model the inner data. It's an example of what I call a compound field. These fields manage their own schema and create a complex blob of HTML in hook_field_formatter_view. They may use Entity API's property information in order to expose the data model to other modules, but they don't follow the core entity-field relationship that RDFa output in Drupal relies on.

Themers overriding field templates

One of the great things about Drupal is the granularity of the theme layer. For advanced themers, it is easy to override just a small part of the HTML output without having to repeat the template code for the parent or child elements.

One of the most common things to override is field output. But since theme_field places the RDFa in the wrapping element that the themer is trying to change, it is easy for themers to blow away the RDFa or add markup that changes the meaning of the RDFa in the process.

I think the changes that microdata necessitates will help us take care of these problematic issues.

1. Microdata will only be output by fields that have intentionally enabled output. This means the maintainer or a contributor will have some knowledge of what the output is supposed to look like... who knows, they might even write tests for it!
2. Because field formatter developers will need to intentionally place the itemprop variables within their hook_field_formatter_view implementations anyway, it wouldn't be too much extra work to enable mappings for compound fields.
3. Themers are less likely to be altering the things output by hook_field_formatter_view, so will be less likely to interfere with the metadata output.

The challenge

The challenge now is creating an easy to use API that passes terms for mappings from the microdata module to field formatters, enabling (in as foolproof a way as possible) the field formatter to place the terms. I have a start on one, but would really like some feedback from the people who will actually have to use it.

Who's up for the challenge?

If you've made it this far, I'd say there's a high probability you are ;)

I would like to have a BoF at DrupalCon London, I hope others want to join. I'm looking forward to involvement and input from:

• Field formatter developers
• Advanced themers
• People who really like reading specs
• Those passionate about DX (developer experience)
• People with other relevant knowledge who I inadvertently forgot