[uf-discuss] Process to handle decentralized creation of new microformats?

Sun Oct 1 08:45:23 PDT 2006

Costello, Roger L. wrote:
> What happens when creating microformats becomes decentralized; that is,
> when communities go off and create their own new microformats?  
> 
> For example, one community might create a microformat for aquarium
> tanks...
> ...
> A separate, independent community might create a microformat for
> artillery tanks....
> 
>      <div class="tank">
>          ...
>      </div>

I think this illustrates the need to choose unambiguous terms where 
possible and, for these examples, classes like "aquarium" and "military" 
would be better choices.

> Alas, we have two tank microformats with totally different semantics.
> 
> This "microformat name collision" problem might lead to the suggestion
> to use namespaces for microformats.  

We already have the profile attribute though it's not always used by 
authors.  If such a collision occurred, it probably wouldn't be very 
likely that the both aquarium and and military format would be used on 
the same page.  However, it is theoretically possible that two 
associated, yet conflicting formats may arise in the future.

> Thus, the aquarium community associates their microformat with this
> namespace: http://www.aquarium.org
> Now their microformat is used as such:
> 
>     <html xmlns:aquarium="http://www.aquarium.org">

Use of xmlns is not appropriate for microformats because there is no 
concept of XML Namespaces in text/html, which is what most people use.

>           <div class="aquarium:tank">

The class attribute is not a QName, so that won't work even in XHTML. 
Besides, QNames have other problems associated with them, one of which 
you pointed out:

> But using namespaces in microformats will trigger problems in other
> technologies, such as CSS. 

(There are many other problems with QNames as well, though they're not 
really relevant to microformats, so I won't go into them now.)

The namespace problem has been looked at by many others in the past. 
Some proposals I remember reading about, which haven't really taken off, 
include:

<link rel="profile" href="http://example.org/ns/aquarium" title="aq">
<div class="aq.tank">

<link rel="schema.XFN" href="http://gmpg.org/xfn/" />
<a rel="XFN.met" href="..." />

http://web.archive.org/web/20041110195640/http://protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm

Then there's the whole issue about namespaces being confusing for 
authors, which is claimed by some people I know.  There are some, 
including people like Ian Hickson, who are quite vocal about this, 
particularly because it adds complexity for both authors and UAs.

Currently, I think the best approach is for microformats to be designed 
with simple vendor prefixes, much like the way vendors can experement 
with CSS.

For example, a marine biology organisation may develop their aquarium 
format and give each property a "aq-" prefix, at least for the root 
class name.  Similarly, a military organisation may use a "mil-" prefix.

e.g.

<ul class="aq-tank">
   <li class="aq-fish">
   <!-- Or, because the root class is already "aq-tank", this is still 
relatively unambiguous -->
   <li class="fish">
</ul>

<div class="mil-tank">
   ...
</div>

Even microformats.org has adopted a kind of pseudo-vendor-prefix.  Many 
of them begin with "h" (like hResume, hListing, hReview, etc.) or "v" 
(hCard: "vcard", hCalendar: "vcalendar")

This approach solves the CSS problem you mentioned earlier, because 
different authors won't be using different prefixes for the same format.

-- 
Lachlan Hunt
http://lachy.id.au/