[uf-discuss] human readable date parsing

James Craig jcraig at apple.com
Fri May 4 08:19:56 PDT 2007


I almost completely disagree with this. If people are actually  
*using* Microformats as intended, there will be plenty of times when  
the machine data will pass in front of the user (in their calendar  
program for example) for verification. I do however, agree with the  
following.

>> expressed in as little-encoded form as can be gotten away with.

I concur, but what is in dispute here is what "can be gotten away  
with." The abbr-design-pattern has failed for machine data.

Copied the entire email below for context. Tantek, if you post this  
to the wiki, please note it as opinion and give a link to the thread.  
Marking this as fact would misrepresent the views of the Microformats  
group as a whole.


On May 4, 2007, at 7:53 AM, Tantek Çelik wrote:

> (apologies for top posting but this is in response to Al's entire  
> message,
> not to any specific point in particular)
>
> Al,
>
> VERY well written.  That's perhaps the clearest explanation I have  
> seen of
> why it is important to have visible information, even somewhat visible
> rather than invisible.
>
> May I quote what you wrote in part or in full on microformats wiki?
>
> Thanks,
>
> Tantek
>
>
> On 5/3/07 6:18 PM, "Al Gilman" <Alfred.S.Gilman at ieee.org> wrote:
>
>> At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote:
>>> Tantek Çelik wrote:
>>>
>>>> 2. Keep both copies of the data at least somewhat visible to  
>>>> humans so that
>>>> at least *some* human eyes/ears can easily inspect both copies  
>>>> and ensure
>>>> that they have not diverged.
>>>
>>> For the sake of argument, though: assuming that those human
>>> eyes/ears use a microformat-consuming tool/extension/etc, this can
>>> still happen. If I have a page with, say, contact details marked as
>>> a hcard, and human users export it to Outlook,  they'll be able to
>>> see (and ensure) whether or not the generated vcard details in the
>>> "add to address book" dialog match the page's visible details or  
>>> not.
>>>
>>> After all, isn't that what microformats are there for? Being
>>> consumed by "machines" that can make something useful with them?
>>
>> Almost.
>>
>> They are there so that people and machines can share info.
>>
>> If the machineable info is not routinely passing through the
>> consciousness of the communicating principals (that is, people), then
>> it must be expected that the machine and the person will frequently
>> have different values for the same datum. Not a good thing.
>>
>> The old saw is, "out of sight, out of mind."  In this case it is "use
>> it or lose it (it's validity)" for data.
>>
>> Microformats are to eliminate the mumbo-jumbo quality of the data
>> the machines deal with; rather to give them the same many-eyeballs
>> 'bazaar' checking support as the virally-maintained meanings of plain
>> English (Chinese, Arabic or what have you...).
>>
>> That's a little overstated, but the devil is in the details.
>>
>> If in some community of communication, the data is routinely
>> extracted into view often enough so that bad data tend to get weeded
>> out, then the storage or transmission form doesn't have to be
>> directly comprehensible by people. But one of the virtues of markup
>> languages is just how much of the info is directly under the quality
>> control of people; expressed in as little-encoded form as can be
>> gotten away with.
>>
>> Al
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss




More information about the microformats-discuss mailing list