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

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Tuesday, October 05, 2010 4:24 AM
To: Suresh Chitturi
Cc: public-device-apis@w3.org
Subject: Re: ACTION-278 - Propose harmonisation descriptions for
Contacts fields


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-xUsPNdDRGSnFZTTAwU3RVdzh
VZ1dOaUxCaVE&hl=en&authkey=CMzj_YcH
>
<https://spreadsheets.google.com/ccc?key=0AlxhCK-xUsPNdDRGSnFZTTAwU3RVdz
hVZ1dOaUxCaVE&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 :

Suresh>> The reason is used timestamp is that is precisely indicative of
semantics, and given that CAB uses "updated" for notifications which is
not the same as PoCo's notion of 'updated'. My preference would be to
use 'revision', if you are not happy with timestamp.

>
> 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.

Suresh>> great!

'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(tm),
> 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.

Suresh>> No problem. In fact this is what we agreed during the call. I
will add this to my "todo" list!

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?

Suresh>> Yes, I think I understand your point. I was struggling with
this as well for the exact reason that we may have more formats in the
future. 
Actually I would be fine with not mention any format at all at this
stage with an expectation that we will have something in the Annex, or a
separate section talking about our design approach and compatibility
with other formats.

>
> 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.


Suresh>> Thanks Richard.

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

- Rich

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 5 October 2010 13:27:08 UTC