Contacts API i18n Review first cut (I18N-ACTION-43)

Here's my first try to review Contacts API. Any suggestions/comments are greatly appreciated.

Review spec at http://dev.w3.org/2009/dap/contacts/

find()
1. Does it search by ignoring cases? If so, does it take the Unicode casing algorithm into account? 
2/ Does it search by using Unicode normalizations? 


vCard
1. Which version of vCard is supported? 
2. Does it support CHARSET type parameter defined in vCard 2.1, which was eliminated in vCard 3.0? Outlook 2010, for instance, generates vCard 2.1 with CHARSET type parameters.
3. Outlook and some East Asian vCard providers such as mobile phones use "X-" proprietary extension fields to represent reading/phonetic information (see below.) How much do you care interoperability with such providers?


Multiple family names

Personal names around the world[1] indicates that there are some cases where multiple family names are required. I'm not sure whether we should ask the spec to incorporate this by making familyName as an array of strings or not, as one can set multiple words in the property anyway, and doing so may affect vCard format. Any opinions?


Reading/Phonetic Issue

Some scripts such as East Asian scripts requires fields to indicate how to read and/or pronounce values, since there could be multiple ways to read a written text. Reading/phonetic field is not only helpful to know how to read/pronounce his/her name, but also for sorting and grouping since sorting and grouping are usually done by reading/phonetic rather than written text in such scripts.

Properties that should consider adding reading/phonetic information are: familyName, givenName, middleName?, ContactOrganization.name, categories? (fields with "?" postfix are low-priorities)

There are a few ways to solve this issue:

1. Add properties for fields that has reading/phonetic information associated. For instance, Microsoft MAPI/Outlook API adds 3 fields for this purpose; YomiFirstName, YomiLastName, and YomiCompanyName ("Yomi" stands for "reading" in Japanese.) 
2. Use an extension of pronunciation attribute[2] defined by IMC. In this case, it is helpful to have utility functions to split reading and display from combined strings, and vice versa. Usually, input and display fields for reading/phonetic are separated from the display text. The function to combine reading/phonetic with display in this syntax is helpful to build vCard strings. 
3. There are other methods to embed reading/phonetic information into Unicode strings such as using INTERLINEAR ANNOTATION characters, but since the spec relies on vCard, and since vCard has its own method to embed the information, it is probably preferable than other methods. 

Here's one of the common ways to represent forms in East Asian:

First Name:  [   ]
  Reading:   [   ]
Other/given Names:  [   ]
  Reading:  [   ]
Company Name:  [   ]
  Reading:  [   ]


[1] http://www.w3.org/International/questions/qa-personal-names
[2] http://www.imc.org/pdi/vcard-pronunciation.html

Regards,
Koji

Received on Friday, 17 June 2011 16:51:00 UTC