Re: [VCARDDAV] vCard revision - AN and RELATED;TYPE=partner

[Sly Gryphon <sgryphon at computer.org>]

The AN and RELATED;TYPE=partner fields are connected, so it is probably 
worth combining the dicussion on them.

>>>>>
Simon Perreault wrote:
Recently I posted my personal reasons for considering an extension for 
inclusion
in vCard 4. They were fairly well received. Here they are:
- The extension provides functionality that was present in vCard 3 or 
earlier.
- It provides functionality that is necessary for extensions to build upon.
- It is needed by a majority of vCard implementations.
<<<<<

* On AN:

Well, I think that anniversary better meets those criteria (and is more 
important than) than date of death (DDAY), particular as an existing 
field in applications, e.g. Outlook 2007 has Birthday and Anniversary 
fields, but not date of death (I think Evolution also has anniversary 
but not death).

In fact, once date of death is set, a lot of the other fields becomes 
redundant/useless (except maybe if you are John Edwards), e.g.

FN: Bob Smith
DDAY: 20080105
ADR: Rookwood Cemetary, Six feet under
TEL;TYPE=cell: We buried a cell phone with him, but the battery has 
probably run out by now

I would suggest dropping DDAY, but including AN.

* On RELATED;TYPE=partner:

It just seems kind of strange to have child (and parent), but not 
spouse/partner. e.g. "Hi Alice, how are the kids Jack and Jill, and your 
parents Carol & David (and your brother Fred)" ... and not mention their 
partner.

In fact, I would have thought partner/spouse was _more_ important than 
children (and definitely more important than parents).

In relation to the inclusion criteria, this is a used field, for 
instance Outlook 2007 has "Spouse/Partner" in the personal section, but 
not children (and certainly not parents). It also has Manager and 
Assistant in the business section, and these are probably what I see as 
the top three (Manager, Secretary/Assistant, and Partner/Spouse), with 
Children as maybe fourth -- at least these are the fields I would use.

I think Evolution has the same three (manager, assistant, spouse), and 
Rolodap has secretary, spouse, and children.

The main problem seems to be not the importance of the field, but that a 
consensus can't be reached on the naming: it is worried that partner 
might be confused with business partner, whilst spouse might be seen as 
too restrictive, and alternatives like domesticPartner or 
partnerOrSpouse seem too long (or corny). I think it is silly to leave a 
field out simply because you can't agree on the name (whilst putting in 
less important ones).

Presuming we want the field to cover more than just marriage, then the 
label just needs to be "partner", and a clear description as "spouse or 
partner" will have to suffice (if implementers don't read the 
descriptions of the fields then there are probably bigger problems than 
confusing "partner" with "business partner", and if they confuse it with 
"tennis partner" well I don't think there is any hope).

If "partner" still isn't sufficient, a thesaurus can provide a range of 
alternatives: "companion", "mate", "consort", "betterHalf", "steady", 
"significantOther", "spouseEquivalent", "domesticPartner".

(In fact, simliar to AN/DDAY, I would even suggest dropping TYPE=parent 
and including TYPE=partner).


These fields clearly do not fall under criteria 1 or 2, but can you 
really say that DDAY and RELATED;TYPE=parent are needed by more vCard 
implementations than AN and RELATED;TYPE=partner?

Sly