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

[Simon Perreault <[e-mail]>]

On 2010-04-07 11:20, Javier Godoy wrote:
> It is not the same problem, as I'm not talking about modifying the
> language-versioned property, but another different property that is
> intended to have the same value in every instance. For example,
> modifying EMAIL in:
>
> BEGIN:VCARD
> VERSION:4.0
> FN:John Doe
> EMAIL:: [e-mail]
> BIRTH;LANGUAGE=de-DE:Köln
> END:VCARD
>
> BEGIN:VCARD
> VERSION:4.0
> FN:John Doe
> EMAIL:: [e-mail]
> BIRTH;LANGUAGE=en-US:Cologne
> END:VCARD
>
> Clearly it is not an issue if multiple instances of the same property in
> different languages are allowed:
>
> BEGIN:VCARD
> VERSION:4.0
> FN:John Doe
> EMAIL:: [e-mail]
> BIRTH;LANGUAGE=de-DE:Köln
> BIRTH;LANGUAGE=en-US:Cologne
> END:VCARD

Ok I understand.

But this issue would be solved by the client application, which would 
present a unified interface with only a single email field.

> What do you mean by "not repeating data"? Actually this approach asks
> for repeating data, as FN and EMAIL in my example above.

You're right. I was referring to the LANGUAGE property in each vCard and 
your proposed LANGUAGE parameter for the RELATED property. Clearly there 
would be more repeated data with separate vCards, and I don't like this.

> Yes and no. The value of RELATED would not be a URI identifying a single
> vCard instance (as I understand it is the intent of RELATED), but a
> *set* of instances (with the actual instance being decided by the
> negotiation mechanism). If it is allowed, it should be explicitly stated.

Ah, right. If we choose to go this way, I'll make sure to mention it.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org