[uf-discuss] Definition of Microformats

[Angus McIntyre]

At 18:57 -0600 27.02.2007, Scott Reynen wrote:
>On Feb 27, 2007, at 5:15 PM, Angus McIntyre wrote:
>
>We're trying to model publishing behaviors, not change them and
>certainly not restrict them.  If someone publishes something that
>doesn't match a microformat standard, parsers should be able to
>deal with that by checking for valid data.  We should be actively
>*encouraging* experimentation with publishing meaningful HTML.
>Meaningful HTML is never litter; it all adds to a more semantic web.
>Meaningfulness is not defined by microformats.  We have no monopoly
>on these ideas, and pretending we do is harmful.
>
>>  While that might encourage parser builders to make their parsers robust,
>>  it's probably not a good thing overall.
>
>It is a good thing overall.  What's not a good thing is this notion that
>people need some sort of approval from us to use more descriptive markup.

That wasn't what I was suggesting, and I understand and agree with 
your points above.

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.

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,

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

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.

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).

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.

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.

>  ... We should be absolutely clear that no one needs permission to change
>  their HTML markup.

Amen to that.

Angus