hCard history and extensions (was Re: [uf-discuss] Date of Death in hCard)

[Jeremy Keith]

Jim asked:
>> <p class="hcard vevent">
>>   <span class="fn summary">Charles Darwin</span> was
>>   born on <abbr title="1809-02-12" class="dtstart bday">February  
>> 12, 1809</abbr>
>>   and died on <abbr title="1882-04-19" class="dtend">April  
>> 19,1882</abbr>.
>> </p>
>>
>
> I don't quite understand - I can see that April 19, 1882 is the end  
> date of an event, but how do I know that the event in question is  
> the life of Charles Darwin? ie. how does a parser figure out that  
> Darwin died on 19th April 1882 from the markup above?

Because the "summary" for the vevent is "Charles Darwin".

>  Is a date of death defined as a dtend which has been immediately  
> preceded by a date with a class of bday?

It isn't necessary to make any such inference because all the  
necessary details for determining the start and the end of the life  
are already provided entirely within the hCalendar data. A person's  
life is an event.

hCard: the person "Charles Darwin" has a formatted name of Charles  
Darwin (given-name: Charles, family-name: Darwin).

hCalendar: the event "Charles Darwin" has a start date of February  
12, 1809 (dtstart: 1809-02-12) and an end date of April 19th, 1882  
(dtend: 1882-04-19).

The personal information is contained within the hCard (first name,  
last name). The event details are contained within the hCalendar  
(start, end). There is some crossover (the formatted name of the  
person is the same as the summary of the event) but that's absolutely  
fine: microformats are designed to be embeddable.

As long as you use the right format for the right data, everything  
can be encoded just fine. The problems arise when you try to use one  
single format to encode everything.

It kind of reminds of the tools we use for front-end development:  
HTML, CSS, JavaScript. As long as you use the right tool for the job  
(HTML for structure, CSS for presentation, and JavaScript for  
behaviour), then everything is hunky-dory. The problems start when  
you try to get one tool to do all the work. If I had a penny for  
every time I heard people ask for "CSS-only" solutions for drop-down  
menus and other behavioural effects, I'd be a rich man.

With hCard (and vcard) the presence of the "bday" field is a bleed- 
over from event data (akin to the :hover pseudo-class in CSS). If  
anything, rather than talking about adding "date of death", we should  
be discussing the removal of "date of birth" (not that I'm seriously  
suggesting that).

Anyway, my point is this: what you are trying to represent with date  
of birth, date of death and lifespan is not contact information, it  
is event information (start, end, duration). Use the right format for  
the data and you can encode what you want without extending either  
format.

As for parsers, I think it would be relatively trivial to have a rule  
that states "If the fn of an hCard (which is not also an org) is  
equal to the summary of an hCalendar, the dtstart and dtend dates of  
that hCalendar represent the lifespan of that person." The presence  
of combined "bday" and "dtstart" values in a class attribute *could*  
be used to reinforce that assumption.

Bye,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/