[uf-discuss] Definition of Microformats

[Scott Reynen]

On Feb 27, 2007, at 9:43 PM, Angus McIntyre wrote:
> I think I started off slightly on the wrong foot, because I wrongly  
> assumed that hRelease was something that had already been raised in  
> this community. In fact, it appears to have emerged at http:// 
> www.socialtext.net/hRelease without ever being listed as a proposed  
> or possible microformat at microformats.org. I'm certainly not  
> arguing that only "we" should be allowed to propose or define  
> microformats. I am arguing, however, that there's some value to  
> 'interim' names that can be used by enthusiastic early adopters  
> before a standard is defined.
>
> Moving away from the specific case of hRelease, I would say the  
> following:
>
> 1. Early adopters who want to use structured markup should be  
> encouraged, not least because that generates 'examples in the wild'  
> that will guide the standards process. I think we're in agreement  
> on that point.

Great.

> 2. Using the likely name of a microformat 'prematurely' or  
> inconsistently is problematic (although the problems are not  
> necessarily very serious) for a few reasons including:
>
> a. Even if robots can handle non-compliant samples (as they  
> should), it makes them do unnecessary work and,

Handling non-compliant input will always be necessary, because  
publishers will always make mistakes.  That's just part of writing a  
microformats parser.  It's not a particularly hard part either.  If  
you can't figure out what to do with something, you just don't do  
anything with it.

> b. Because much HTML is learned by example, we have an interest in  
> promoting a higher proportion of 'good' examples,

The solution to the proliferation of bad formats is to make the  
formats better.  People will use the better formats because they're  
better, and the bad formats will gradually disappear.

> c. In general, the usefulness of a microformat is 'diluted' if the  
> proportion of conformant samples is low compared to the proportion  
> of non-conformant samples.

How so?  The only hCard's validity I care about is the one I'm trying  
to use.  If the rest of the web were full of invalid hCards, that  
wouldn't make the one I'm trying to use any less useful.

> To expand briefly on (b) above, imagine a naive developer who has  
> heard about the wonderful new microformat hThing. They find a Thing  
> marked with the class="hThing", open it up in a text editor and say  
> "Ah, so that's how it's done.". They then reproduce the structure  
> in their documents. Unknown to them, the page was drawn up by an  
> early adopter using their notion of what hThing might later turn  
> out to be. When ThingBot, the Thing Crawler (tm) totally ignores Mr/ 
> Ms Naive Developer's page, s/he will be frustrated. "But I used  
> hThing!"
>
> "They should have read the spec", you say. In an ideal world, they  
> would, but in a less-than-ideal world, there's still an interest in  
> trying to encourage as many examples of good practice as possible,  
> for the benefit of those who don't read specs (and - by extension -  
> for the benefit of everyone who stands to profit from use of  
> microformats, which is all of us).

I see two solutions to this problem:

1) Discourage Mr Naive Dev from implementing the spec until it has  
been "blessed" for use
2) Continuously improve the spec, and encourage Mr Naive Dev to  
update when the spec improves

I think 2 is clearly better, not least because it indirectly takes  
care of 1, as early drafts are revised much more frequently, so  
publishers will be more hesitant to use them if they're not prepared  
to frequently update.

> 3. Suggesting an alternative name that could be used in place of as- 
> yet-undefined microformats may avoid these problems and, as a  
> bonus, allow more efficient collection of real-world examples.

As-yet-undefined microformats should really have no names, though we  
often name things before we have any reason to.  I'm all for using  
alternative names, and I suggest common English for that.  If we're  
talking about a thing, let's use class="thing".  If we're talking  
about a song, let's use class="song".  Then when we finally establish  
a microformat for songs, we can call it something relatively unique  
like "hSong" and avoid any name conflict.  I think this is pretty  
much what we already do, except we've lately grown fond of that "h"  
and started attaching it to common words for no apparent reason.  So  
let's stop doing that.

> While I probably don't feel strongly enough about this to volunteer  
> to be burned at the stake for my beliefs on the subject, I think  
> that suggesting the use of 'experimental' microformat names to  
> preshadow a future microformat would not harm and might possibly help.
>
> And that's all I really wanted to say.

Sorry if I came off as burning you at the stake.  All of the recent  
discussion of governance has me worried people are delegating far too  
much authority (and too much responsibility) to this community.

Peace,
Scott