Subject: Re: [VCARDDAV] vcardrev+xml next steps

From: Andy Mabbett <[email-masked]>
Date: Sun, 28 Nov 2010 11:04:05 +0000

On 10 October 2010 16:53, Tantek Çelik <[email-masked]> wrote:
> Based on a thorough section by section review[1], the changes and
> feedback I have for vCard4 draft 13 fall into a general outline as
> follows.

> 3. Drop other new vCard4 properties from the core and if they seem to
> make sense, move them to extension specifications instead where they
> can prove themselves out, e.g.:

> Potential Extensions:
> * genealogy extension (BIRTH location, DEATH location, DDAY datetime
> of death, maybe more from GEDCOM)

Those properties are not related solely to genealogy; as has been
described previously.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 28 Nov 2010 11:17:23 +0000

P.S.

On 10 October 2010 16:53, Tantek Çelik <[email-masked]> wrote:

> * KIND - vCard should not expand scope like this. For new kinds of
> objects new vThings should be created, and can be, outside the vCard
> spec.

I'm very surprised to see this claim made; hCard, derived wholly from
vCard; infers KIND by the use of combined parameters,for example if a
value is classed (in the HTML sense) as FN, it is understood to refer
to a person, but if both classes FN ORG are applied to the value, it
is deemed to refer to an organisation or venue.

More on this at:

     http://microformats.org/wiki/hcard#Organization_Contact_Info

     http://microformats.org/wiki/hcard-brainstorming#Named_locations

An explicit KNID property would allow this distinction to be carried
back into vCard.