[microformats-discuss] Carl Beeth raises an interesting point
Tantek Ç elik
tantek at cs.stanford.edu
Fri Jul 8 09:47:36 PDT 2005
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?
> 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
> 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
> 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
> 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.
More information about the microformats-discuss