Re: [VCARDDAV] Questions about vCard 4.0 (draft rev-11)

["Javier Godoy" <[e-mail]>]

On 2010-06-23 9:32 AM, Simon Perreault wrote:

> On 2010-06-23 03:43, Javier Godoy wrote:
>> Since ORG is (0,n) now it makes sense to define SORT-STRING as (0,n),
>
> I disagree. FN is (1,n). We're still in the same situation.
>

I though that FN was (1,n) because the name of the same person may be written 
in different languages (or scripts), and not because one person could have 
different names in the same language. On the other side, ORG is (0,n) not only 
because the name of the same organization may be given in different languages, 
but also because the same individual may be related to several organizations.

> Suppose you have multiple FN properties. Which one are you going to use
> for sorting? The first one? It wouldn't make sense to pick e.g. the
> second one because there's nothing guaranteeing that all second FN
> properties in all vCards have anything in common. Also, the order of
> properties can be changed by any intermediate system since order doesn't
> matter.

I would use the preferred one, if the PREF parameter is provided. In case of 
tie, or if no SORT-STRING is provided,  would choose any of them (i.e. 
undefined)
But, why did we allow FN to be (0,n)?

> Since we're in the same situation with ORG, I don't see why we wouldn't
> solve it exactly in the same way with a separate property, e.g.
> ORG-SORT-STRING.

If one wouldn't need to store the kana for every ORG, that would be fine. As 
explained below, a conservative guess would be that it might not be the case.

org1.ORG;LANGUAGE=ja;PREF=80:日本の組織  # "Japanese organization"
org1.ORG;LANGUAGE=en;PREF=80:Japanese organization
org2.ORG;LANGUAGE=ja;PREF=90: もう一つの日本の組織
org2.ORG;LANGUAGE=en;PREF=90:Another Japanese organization
name.SORT-STRING:みやかわ;だいすけ
org1.SORT-STRING:にほんのそしき
org2.SORT-STRING:もう ひとつ の にっぽん の そしき

Would collate by にほんのそしき (Kana for "Japanese organization"). If it is 
changed to:

org2.ORG;LANGUAGE=ja;PREF=70: もう一つの日本の組織
org2.ORG;LANGUAGE=en;PREF=70:Another Japanese organization

It would collate by もう ひとつ の にっぽん  の そしき (kana for "Another 
Japanese organization")


> Now, one thing that I like about your example is the use of the LANGUAGE
> tag. We need to at least add an example where the LANGUAGE tag is also
> applied to the SORT-STRING property.

LANGUAGE is not a parameter for SORT-STRING. Adding a LANGUAGE would allow 
different SORT-STRINGs for different languages while preserving (0,1) 
cardinality.

> Example:
>
> ORG;LANGUAGE=ja:日本の組織  # "Japanese organization"
> ORG;LANGUAGE=en:Japanese organization
> ORG-SORT-STRING;LANGUAGE=ja:にほんのそしき
>
> (I'll figure out an equivalent example in French since we can't have
> Japanese characters in RFCs...)

I don't think there is an equivalent example in US-ASCII.

As I understand this issue, ORG and FN use unsortable ideograms (kanji), while 
SORT-STRING uses a syllabic script (kana) which is appropriate for collation. 
Personal names are represented in kanji in normal, everyday writing, while 
their collation sequence in a directory (or a catalog) follows kana 
representations [1], and both are required when you fill a form (though some 
algorithms exist, maybe converting properly from kanji to kana is not a 
straighforward task, I don't know)

I think we should provide a layman's description of kanji/kana, so that we can 
render the example as:

ORG;LANGUAGE=ja:<kanji for Japanese organization>
ORG;LANGUAGE=en:Japanese organization
ORG-SORT-STRING;LANGUAGE=ja:<kana for Japanese organization>

[1] http://www.dcmipubs.org/ojs/index.php/pubs/article/viewFile/22/13


Best Regards

Javier