[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought

[Breton Slivka]

On Tue, Jul 1, 2008 at 9:49 AM, Breton Slivka <zen at zenpsycho.com> wrote:
> On Tue, Jul 1, 2008 at 3:11 AM, Ben Ward <lists at ben-ward.co.uk> 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.