Re: CfC: publish FPWD of Contacts API; deadline Feb 8

Hi,

I actually had phonetic first / last names in our initial draft [1]. However, since it is a vCard extension (and there are many others) we decided to remove it.
In practice, the applications could use their own database to store such extensions and not loose any functionality.

However, you are right that the vCard format is extensible and I think there may be some value in allowing the same in the Contacts API, especially for commonly-used extensions (such as phonetic first / last names) which can potentially be used by several applications. This would also avoid synchronization problems between the different databases for the application.

The API could look like:

[NoInterfaceObject]
interface VCardExtension {
  attribute DOMString extension; // e.g. 'X-PHONETIC-FIRST-NAME'
  attribute DOMString data;
};

[NoInterfaceObject]
interface ContactProperties {
  // ...
  attribute VCardExtension[] vcardExtensions;
};

While this proposal would probably be sufficient to attach additional information to the contact card and display it in the application. It is likely inefficient for the use cases you mention: searching and sorting. Such operations would have to occur on application side and the application would have to iterate through the vcardExtensions array to find the one it is interested in. I guess we could avoid iterating by using Object type instead of VCardExtension[] but Object is very generic and allows for complex / arbitrary structures.

What did you have in mind in term of extensions to the current API to fit the needs you have?

Kr,
Christophe Dumez

[1] http://sysapps.github.com/sysapps/proposals/Contacts/input_docs/contacts_intel.html#contactproperties-phoneticgivenname

On Feb 1, 2013, at 8:20 AM, Tomoyuki SHIMIZU <tomoyuki.labs@gmail.com> wrote:

> Hi,
> 
> One comment for Contacts API below:
> 
> I would like to suggest an optional attribute of contactProperties for private extensions, which could be applied to arbitrary purposes.
> 
> The vCard specification allows us to define private extensions[1], which are widely applied to various purposes[2]. For example, as one of its use cases, extensions X-PHONETIC-FIRST-NAME and X-PHONETIC-LAST-NAME, which indicate furigana (alternative spelling for kanji usually written in katakana or hiragana)[3], are essential for Japanese people. In such a case, though kanji names are shown in contacts list, Japanese usually use furigana for search query, sorting order, etc.
> 
> Best regards,
> Tomoyuki
> 
> [1] http://tools.ietf.org/html/rfc6350#section-6.10
> [2] http://en.wikipedia.org/wiki/VCard#vCard_extensions
> [3] http://en.wikipedia.org/wiki/Furigana
> 
> 
> (2013/02/01 10:43), Wonsuk Lee wrote:
>> Colleagues,
>> 
>> This is a Call for Consensus (CfC) to publish a First Public Working Draft (FPWD) of the Contacts API spec using the following ED as the basis <http://sysapps.github.com/sysapps/proposals/Contacts/Contacts.html>.
>> 
>> This CfC satisfies the group's requirement to "record the group's decision to request advancement".
>> 
>> By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents.
>> 
>> If you have any comments or concerns about this CfC, please send them to public-sysapps@w3.org <mailto:public-sysapps@w3.org> by February 8 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal.
>> 
>> For the chairs,
>> 
>> Wonsuk.
>> 
>> =========================================
>> 
>> *이 원 석(Wonsuk, Lee) / *Principal Engineer, Ph.D
>> 
>> *SAMSUNG ELECTRONICS Co., LTD. (**三星電子)*
>> 
>> Mobile: +82-10-5800-3997
>> 
>> E-mail: wonsuk11.lee@samsung.com <mailto:wonsuk11.lee@samsung.com>
>> 
>> http://www.wonsuk73.com/, twitter: @wonsuk73
>> 
>> -----------------------------------------
>> 
>> *Inspire the World, Create the Future !!!*
>> 
>> =========================================
>> 
> 

Received on Friday, 1 February 2013 11:23:03 UTC