[microformats-discuss] Carl Beeth raises an interesting point

[Tantek Ç elik]

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

>> I think we need to identify the link so as to not put to much burden
>> on the user agent. ex:
>> you decide to grab a minimal hcard from a web page. How does the
>> browser know which link inside the hcard contains the full card, for
>> that matter how does the browser know that there is a link to a
>> complete hcard. In essence we would need to program the agent to fetch
>> and scan all the urls within the hcard.
>> So identifying the link is much easier on the user-agent/crawler. Of
>> course, identifying the link adds some work for the author but less
>> than if he needed to duplicate all the information.
> 
> Basically, Carl is proposing something like:
> 
> <a href="http://thecommunityengine.com/webcites"
> class="xfolk">returns xFolk entries</a>
> 
> to specify that the URL returns xFolk entries to extend his point
> beyond the purely hCard specific.  I was sceptical of this idea at
> first, but now think it makes a lot of sense and might actually be a
> good convention to adopt as either a meta or basic microformat (can't
> quite decide which, maybe a new category meta-basic).
> 
> Any thoughts?  I may just check with Carl and see if he wants to add
> this as a more formalized microformats proposal.  I bet a lot of
> people are experiencing this problem.  I can certainly see it in a
> project I'm about to start.

I'm not convinced.

This feels like one of those "theoretically this could be a problem"
problems.

Basically, I want to avoid designing any kind of feature like this without
someone actually *building* a solution and *actually* having the problem.

There are *tons* of such "theoretical" problems, that, when you actually
develop build your solution, turn out to not be problems at all.

For example, this exact fear of "theoretically this could be a problem"
reasoning is why people rush off and over-use namespaces when 99% of the
time they are completely unnecessary.

The problem with design by "theoretically this could be a problem" is that
it always prematurely complicates designs, formats, solutions, etc.  Or
worse, it causes you to worry for *years* about "theoretical" problems, and
never finish your solution until other folks in the market have passed you
by.

So in many ways, it is anti-design pattern.

It is against the microformats way.

I'd also say this might be a better discussion for the microformats-dev
list, but that would require that there be one or more specific
implementations that we would be able to try out and use to understand the
problem.

Carl, Bud, do you have an implementation that we can try out to actually see
the problem?

Thanks,

Tantek