[microformats-discuss] Carl Beeth raises an interesting point

[Tantek Ç elik]

On 7/8/05 8:45 AM, "Bud Gibson" <bud at thecommunityengine.com> wrote:

> On Jul 8, 2005, at 10:49, Tantek Çelik wrote:
> 
>> Carl, Bud, do you have an implementation that we can try out to
>> actually see
>> the problem?
>> 
>> Thanks,
>> 
>> Tantek
> 
> Tantek:
> 
> I don't think this is an anti-design pattern as Carl actually raised
> the point relative to a problem he was having.

Agreed.  Carl's question was a good one (I just went back and found his
email and responded to his question in particular).

> So, I present that to
> you as the implementation issue.

It's an authoring issue, not an implementation issue.  If you go back and
read Carl's email, he is talking about a [theoretical] "user agent/crawler",
not one that he is writing.


> I understand your concern about getting lost in theoretical issues.
> It seems like the likelihood of that happening with microformats is
> very slight.

I do not share your optimism.  I think we have a very small core group of
microformats enthusiasts right now that understand the problem of falling
into the theoretical issues trap, and yet, 99% of the people in our industry
designing specs for W3C, or IETF, or whatever, are *constantly* falling into
this trap.  And the funny thing is, most folks *enjoy* it!  (I have to admit
this myself -- there is a certain "mental exercise" satisfaction that one
gains by analyzing and attempting to solve theoretical problems).

Thus the odds that any person new to microformats will fall into this trap
is *very* high.  Therefore we have no choice but to be eternally vigilant,
and shoot down theoretical issues as quickly as possible, or push back and
say, show me a real example/implementation that demonstrates the problem.


> Basically, if you propose a microformat, and it falls
> flat, then that's over.

Yes, that is definitely a very pragmatic aspect.  But I would say that the
goal of this community is to provide a place where you can propose the
precursors to a microformat, e.g. problem statements, and have folks give
you feedback that would increase the chance of your microformat proposal
*not* falling flat, and the only expense being sending one or two emails and
hopefully only waiting a day or two.  That doesn't seem that high a price to
pay.


> You'll also note that the solution I propose
> is very light weight.

It is by itself, but the pattern it implies is not light weight.  The
introduction of a new class for each microformat just to identify it seems
heavy weight.


> I'm not sure what the fuss about "anti-design" patterns is in light
> of these facts.  Concerns about anti-design are really concerns about
> the cost of design mistakes, and those seem low here.

Yes, the cost of design mistakes is definitely low here.  The "anti-design
pattern" is specifically the use of theoretical problems as a required
constraint.


> At the end, we may just be harboring different conceptions of what a
> microformat is.  I tend to think of them as standardized but
> frequently still experimental approaches to solving existing and
> emerging problems.

I think we agree more than disagree.

Microformats are somewhere between experimental and standardized.

> You are not so keen on the emerging problems idea.

Rather, for microformats, I prioritize "existing problems" above
"theoretical problems", and I think it is wise to do so.

Tantek