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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
