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