Re: [VCARDDAV] LANGUAGE parameter vs. cardinality and PIDs

[Cyrus Daboo <[e-mail]>]

Hi Simon,

--On April 7, 2010 7:58:59 AM -0400 Simon Perreault 
<[e-mail]> wrote:

>> If #1 is applied, we also need a new value for the RELATED type, such as
>> "translation" or "self", for linking vCards instances describing the
>> same individual in diferent languages.
>>
>> RELATED;TYPE=self:http://example.com/directory/en/jdoe.vcf
>> RELATED;TYPE=self:http://example.com/directory/fr/jdoe.vcf
>> RELATED;TYPE=self:http://example.com/directory/en/jdoe.vcf
>
> I think that's a good idea.
>
>> Note that clients won't know which vCard is in which language, before
>> retrieving the instance (we might add a language-param for this case)
>
> With CardDAV we can retrieve only the LANGUAGE property for all the
> related vCards in a single REPORT query with addressbook-multiget. So I
> don't see this as a problem. (And not repeating data could be considered
> desirable.)

One big question is what would the UID values be for all the "alternative" 
cards? Are they all the same or different. If they are the same that would 
pose a big problem for CardDAV as that requires the UID values to be unique 
within an address book collection. But the definition of UID in the draft 
implies that it is unique to "the individual or resource associated with 
the vCard" - which would suggest that the alternatives all have the same 
UID.

So the idea of "alternative" vCards for language is problematic.

In iCalendar we have been thinking about how to handle multiple languages 
(the event publishing folks are very keen to present multi-lingual event 
information). One option we have in iCalendar is to create new 
"sub-components" for the language variants, e.g.:

BEGIN:VEVENT
...
SUMMARY:English
...
BEGIN:LOCALE
LANGUAGE:fr_FR
SUMMARY: Francais
...
END:LOCALE
BEGIN:LOCALE
LANGUAGE:de_DE
SUMMARY:Deutsch
...
END:LOCALE
END:VEVENT

Clients that were aware of the new components could use the properties in 
their locale-specific one to "override" the values in the "base" component. 
Clients unaware would just fall back to using the "base" values. There are 
lots of issues that would have to be worked out with this approach, but it 
is convenient in that the entire event and all localizations are contained 
in one component.

Unfortunately, in vCard we don't (currently) have the concept of a 
sub-component that would allow us to easily do something like this.

At the end of the day I think we need to find a way to make the current 
LANGUAGE parameter work. If that means stating up front that the 
"cardinality" of properties can be "overridden" by LANGUAGE alternatives, I 
think that is fine.

However, one issue with the current scheme is dealing with items with 
cardinality > 1. For example I could today have multiple ORG properties 
with different LANGUAGE parameters. Does that mean they are alternatives, 
or separate? To resolve that ambiguity there would need to be a unique 
identifier on properties that would be the same on LANGUAGE alternatives.

-- 
Cyrus Daboo