On Tue, Jul 1, 2008 at 9:49 AM, Breton Slivka <[EMAIL PROTECTED]> wrote: > On Tue, Jul 1, 2008 at 3:11 AM, Ben Ward <[EMAIL PROTECTED]> wrote: >> I'd like to make a very important point. >> >> On 30 Jun 2008, at 10:38, Breton Slivka wrote: >> >>> if you violate #1, Tantek steps >>> in and says you can't do that. Since it's difficult to overcome the >>> influence and authority of Tantek in this community, comprimising #3 >>> is the only way you can go. Otherwise the argument is just going to go >>> around in circles forever. >> >> To quote the wiki: >> >> "Microformats are not controlled by any individual or organization" >> — >> http://microformats.org/wiki/microformats#microformats_are_not >> >> Disagreement within community members is always likely, such is the nature >> of community. At this point in this community's life, no one person is more >> important than another, and if that were ever to be the case, the community >> and the effort of microformats generally will suffer greatly. >> >> When someone says you 'can't' do something, it's likely in the context of >> the microformats principals. Someone saying 'no' cannot be backed up only by >> their reputation and stature. 'Citation needed', is perhaps the most >> succinct requirement. >> >> The most worrying thing about this message is that anyone should perceive >> the direction of this community as being dictated by one personality's >> viewpoint. That is not the case, and the microformats effort will fall apart >> if it ever was. To make decisions pre-emptively out of this misperception is >> not going to lead us to the best solutions. >> >> Additionally, it may well be that we're dealing with a problem right now >> calls for an exception to a principal. I'm not aware that we've ever >> consciously made exceptions before, so there's no precedent. As such, the >> justification for and the scope of such exception needs to be _very clearly >> documented_ and approached thoroughly. The justification for making an >> exception needs to be held to very careful scrutiny. >> >> B > > > Yes, I know that's the party line, but vehemantly insisting on the > truth of such an assertion does not make it true. Are you seriously > suggesting that there are cases where someone has proposed a solution > involving information hiding, and Tantek HASN'T stepped in, and > immediately put an end to all conversation along those lines? If there > is such a case, I'm quite curious to see it, and I'm also quite > curious to see what else must have stepped in the way to put an end to > that line of solutions. > > Yes, restriction #1, "no information hiding" is a "microformats > community principle", but it's quite obviously Tantek's baby, and in > the past, it's primarily been Tantek who has enforced that rule, and > Tantek's enforcement has been effective. If this reality disrupts your > rose colored idealistic view of the microformats community, well, I > can't help you. You haven't stated a particularly compelling case. > You've only recited community dogma. > > > That said, I actually agree with the rule, and I'm glad it's being > enforced, and I don't mind that it happens to be Tantek that's > enforcing it. It's a good rule, and I understand the reasoning behind > it. All I'm saying is that if we're not going to hide information, and > we're not going to make things difficult for humans reading the > microformat, or humans writing the microformat, violating restriction > #3 is the *ONLY* way to go, until someone happens to pull a magic > bullet out of the air. But I'm honestly not holding out hope. If > nobody wants to violate Rule #1, and nobody wants to violate Rule #2, > we're going to have to make bulkier more complicated parsers. >
Also, I would like to point out, that the restrictions I've listed are not binary. All the solutions I've seen fall somewhere along a continuum, and indeed many existing microformats violate some principle or another to some extent. The ABBR pattern at the center of this debate violates restriction #1 and restriction #2 to some extent. It's semi hidden data that is semi unfriendly to humans. And it's the truth and value of the restrictions #1 and #2, I think, that have led to the failure of the ABBR pattern- It failed because of those violations. And it's especially those failures in restriction #1, and #2 that I think will force a solution that must violate the implicit community "rule" of avoiding complicated parsers. _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss