[microformats-discuss] abbr-design-pattern

[Tantek Ç elik]

On 10/10/05 2:06 PM, "David Janes -- BlogMatrix" <davidjanes at blogmatrix.com>
wrote:

> You'll note that in on the Wiki page I explicitly spell the human vs.
> computer issue:
> 
> | Use the abbr-design-pattern to make text that is human readable also
> | formally machine readable.
> 
> In broader sense, there's two use cases:
> 
> (1) using ABBR to encode machine readable data around human readable data
> 
> <abbr class="dtstart" title="20051010T10:10:10-0100">10 o'clock on the
> 10th</abbr>

Yes.

> (2) using ABBR to encode more formal human data around something less formal
> 
> <abbr class="author" title="Danny Ayers">Danny</abbr>
> 
> I think Tantek is arguing that (1) is good and (2) is not (?).

That's correct.

(1) is a case of the same information being written differently.

(2) is a case of *more* information being invisibly present, namely, the
last name in this case.

If someone is not willing to make some information visible, then we
shouldn't be encouraging them to store that information invisibly, for all
the same reasons that invisible metadata is bad/futile in the first place.

Regards,

Tantek


> Tantek Çelik wrote:
>> On 10/10/05 1:47 PM, "Ryan King" <ryan at technorati.com> wrote:
>> 
>> 
>>> From http://microformats.org/wiki/abbr-design-pattern:
>>> 
>>> 
>>>> *abbr-design-pattern should be avoided, if possible. RobertBachmann
>>>> **why, or under what circumstances? For example, it is quite useful
>>>> with datetimes. Should there not be other potentially analogous
>>>> situations? DavidJanes
>>> 
>>> I'm curious- why do you say this, Robert?
>> 
>> 
>> I actually would tend to agree (despite coming up with the technique), but
>> would phrase it differently.
>> 
>> abbr-design-pattern should be used only when absolutely necessary to
>> distinguish the human readable text from the computer readable data.
>> 
>> And the reason being to better follow the DRY principle.
>> 
>> This is typical for date time related information, and some keyword values
>> (e.g. "type" values in hCard properties), but little else.
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss