hCard history and extensions (was Re: [uf-discuss] Date of Death
in hCard)
Tantek Ç elik
tantek at cs.stanford.edu
Thu Jun 28 10:33:30 PDT 2007
On 6/28/07 9:21 AM, "Andy Mabbett" <andy at pigsonthewing.org.uk> wrote:
> I can see no good reason why an historical, almost accidental,
> relationship with vCard should stop the hCard on that page from also
> including his Date of death (and places of birth and death, for that
> matter).
The decision to base hCard on vCard was an explicit decision (not accidental
in the least), and in fact, predated the name hCard itself.
It started more as POSH actually, that is, I asked rhetorically in September
of 2004 at Foo Camp, what if we used the properties from vCard as class
names in semantic HTML?
It was an easy decision to make at the time (and still now) because vCard is
by far the most dominant contact information standard/schema in existence in
terms of raw data items, and in terms of implementations.
After marking up a few documents and seeing that the use of those properties
"worked", I asked folks for possible names and hCard seemed to be a
reasonable "working name" and it stuck.
The development of hCard (and similarly hCalendar, as I conceived the two
pretty much simultaneously due to similar discussions) very much drove the
"research previous existing formats" portion of the process as well.
I blogged this a bit at the time:
http://tantek.com/log/2004/09.html#d30t1725
I believe that extending hCard is premature at this point.
Rather, I believe it is more important to solidify the current spec/schema,
and resolve outstanding issues and feedback on *existing* functionality
before considering even the possibility of new features for hCard. However,
it is good to capture such ideas anyway as they may be useful in the future,
or possibly in other formats instead.
As far as additions to hCard outside of vCard, please document them on the
hCard brainstorming page:
http://microformats.org/wiki/hcard-brainstorming#Post_vCard_additions
I've added the few I've heard of, but additional documentation could be
added.
For some of these I see quite a bit of utility (e.g. "gender" is often used
in social network searches - an actual application in common use), whereas
others seem to be merely driven by sense of semantic publishing completeness
(e.g. date of death) and not by existing applications.
Finally, any time you find yourself (or anyone else) arguing a positive from
the absence of a negative, please call it out as a logical flaw.
I.e. statements of the form:
"I can see no good reason why ABC
should stop XYZ"
... do not provide justification for XYZ.
Thanks,
Tantek
More information about the microformats-discuss
mailing list