W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2010

Re: ACTION-278 - Propose harmonisation descriptions for Contacts fields

From: Rich Tibbett <richt@opera.com>
Date: Tue, 05 Oct 2010 11:24:26 +0200
Message-ID: <4CAAEECA.2000100@opera.com>
To: Suresh Chitturi <schitturi@rim.com>
CC: public-device-apis@w3.org

Suresh Chitturi wrote:
> Hi all,
>
> The following link contains a detailed proposal to harmonize
> descriptions for Contact fields based on our current API and our
> discussion last week.
>
> https://spreadsheets.google.com/ccc?key=0AlxhCK-xUsPNdDRGSnFZTTAwU3RVdzhVZ1dOaUxCaVE&hl=en&authkey=CMzj_YcH
> <https://spreadsheets.google.com/ccc?key=0AlxhCK-xUsPNdDRGSnFZTTAwU3RVdzhVZ1dOaUxCaVE&hl=en&authkey=CMzj_YcH>
>
> Notes:
>
> - The proposal is based on the assumption that the descriptions are
> provided in our spec without explicit references to other specifications
> (and I have written all of the descriptions based on available language
> from PoCo, vCard and OMA CAB).
>
> - The interfaces are retained with no changes, and only the attributes
> within the interfaces are proposed to be changed in some cases to be
> consistent with other formats. There are two types of changes in attributes.
>
> o Name change: I have made this decision by using the “majority” rule.
> For e.g. if two formats use the same name, I have tried to re-use it in
> favor of the naming proposed by the lone format.

I like all with the exception of the following fields:

updated -> timeStamp: In vCard it's 'rev' and in PoCo it's 'updated'. 
'timeStamp' could mean something else IMO. So perhaps 'revision' or the 
original 'updated' works better here? Either way, it's a naming argument 
and we know where those get us :

>
> o Attribute/field change: I did not introduce new attributes but
> eliminated some based on either not being crucial or not
> consistent/aligned with all the formats in subject

On ContactName interface there will be no 'formatted' attribute but we 
shall keep 'formatted' on ContactAddress? Perhaps there is some logic to 
this?

Agree with simplifying ContactOrganization along the lines you propose.

'relationships' and 'anniversary' removed from the spec already: 
http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0000.html

Just a couple of other points:

- Change of object type of Date object in 'updated/timeStamp' and 
'birthday':  I can live with this.

- Change of 'tags/categories' from ContactField[] to DOMString[]: I can 
live with this and it's inline with vCard.

>
> Based on the proposal, my suggestion is to change the leading sentence
> in the Contact interface as below:
>
> Change:
>
> “The |Contact| <http://dev.w3.org/2009/dap/contacts/#contact-interface>
> interface captures the properties of a contact object. All properties
> included in this interface have a corresponding definition in
> [POCO-SCHEMA <http://dev.w3.org/2009/dap/contacts/#bib-POCO-SCHEMA>] and
> are intended to be direct mappings to attributes also defined in
> [RFC2426 <http://dev.w3.org/2009/dap/contacts/#bib-RFC2426>].”
>
> To
>
> “The Contact interface captures the properties of a contact object. All
> properties included in this interface have a corresponding definition in
> Portable Contacts [POCO-SCHEMA
> <http://dev.w3.org/2009/dap/contacts/#bib-POCO-SCHEMA>] , IETF vCard
> [RFC2426 <http://dev.w3.org/2009/dap/contacts/#bib-RFC2426>], and OMA
> CAB [OMA CAB], thereby allowing the API to be implemented on top of
> implementations supporting these different contact formats.”
>
> (The references I think should be moved to the informative section.
> Further, I think we can move the second sentence altogether to the Annex
> assuming we will provide a mapping of the Contact fields in the API to
> these various formats). For OMA CAB, here is the reference: “Converged
> Address Book XDM Specification", Version 1.0, Open Mobile Alliance™,
> OMA-TS-CAB-XDMS-V1_0, URL:http://www.openmobilealliance.org/”)

As discussed on the conf call last week, starting this exercise on the 
mailing list (or via a collaborative spreadsheet) would be a good start. 
If the exercise proves central enough to the spec we will create a 
suitable annex for it.

One issue with this is that it still includes some formats at the 
expense of other contacts formats. I'd probably prefer this to be a 
living document that can be constantly appended with new fields, format 
mappings, etc after W3C Rec publication. WDYT?

>
> I believe this completes my action-278, and is inline with our
> discussion from last week’s call.
>
> Please note that I will be on vacation starting this Wednesday, and will
> not be available for the next 3 weeks. I’m hoping this proposal is
> fairly easy to understand and does not require my presentation but if
> you have further clarifications on the approach I took, I’ll be happy to
> discuss it after my return.
>
> Richard – I’d appreciate if you can start folding in the proposal (or
> parts of it as appropriate) based on the group’s discussion this week.
>

I will start to fold in the changes pending feedback on the above points.

Many thanks for this specific technical input. It really helps to get 
the conversation moving.

- Rich
Received on Tuesday, 5 October 2010 09:25:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:14 GMT