RE: [Contacts] couple of comments

Before re-naming Categories, I would like to understand a bit further
how tags are used and different from categories? If it is only used for
filtering wouldn't categories solve the purpose?

The reason I prefer to keep the name categories is that it is a
well-defined term and people know how to use it. If we want to cover
tags I would keep it as a separate discussion, without changing the name
categories.

On removing 'mobile' from the list, I am a bit hesitant as it is by far
the most used type in anyone's phonebook after 'name'. Things may be
different in the future but to maintain compatibility we are better off
not removing it.

For impps, one proposal (not so strong) is to name it to either 'imAddr'
(IM Address) or 'ComAddr' (Communication Address). Or make it a generic
address tuple with name/value pair that can take multiple types:
IM/IMAddr, WebAddr/URI, etc.

Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of
richard.tibbett@orange-ftgroup.com
Sent: Monday, January 11, 2010 12:10 PM
To: anssi.kostiainen@nokia.com; public-device-apis@w3.org
Cc: maxfro@opera.com
Subject: RE: [Contacts] couple of comments

Hi, 

Thanks for the feedback.

> On 7.1.2010, at 10.50, ext Max Froumentin wrote:
> 
> > 1. I think that examples would be more instructve if they included 
> > some code showing how to access data from callback objects, 
> instead of 
> > "// do something with resulting contact objects"
> >

Good idea. I'll put something more instructive in this space.

> >
> > 2. "Device implements DeviceContacts;"
> >
> > Why did you choose "implements" over inheritance or 
> PrototypeRoot? I 
> > don't know which to choose myself.
> >

I followed general conventions used elsewhere in W3C such as e.g.
Geolocation [1]

> > 3. "ContactError::CONTACT_INVALID_ERROR."
> >
> > Replace :: with . ?
> >

Right :-)

> > 4. "One or more contexts to associated with the given value"
> >
> > Typo
> 

Fixed.

On 8th Jan 2010 at 6:10pm, Anssi Kostiainen wrote:
> 
> Some additional comments against the current version:
> 
> 4.4.1
> 
> * The categories attribute could be renamed to tags. 
> Categories are not tags but tags can be also categories, 
> right? Also categories name may suggest it is a bounded set.

Agree that 'tags' is a more generic name. Tags can be categories and
groups or even keywords for the purposes of filtering via a find().

> 
> * "The following constants are defined for use in the types 
> attribute for email addresses:
> 'home', 'work', 'mobile', 'personal', 'business'." The mobile 
> is not consistent with the others so it could be dropped. 
> Otherwise we could argue that we should add 'desktop' and 
> 'laptop' as well and the combinations 'home-mobile' and 
> 'work-laptop' etc.
> 

So how about: 'home', 'work', 'personal', 'business' with the option of
adding custom types as required? Or the alternative would be to
extensively define these constants, but I think we can do that later on.

> * impps attribute name could be more descriptive to be easier 
> to remember and type correctly. However, I don't have a good 
> suggestion at the moment :)

I too have no suggestion at the moment to suitably replace 'impps'. :-)

> 
> * impps and phones attributes: "The first object in this 
> sequence is inferred to be the user's preferred/default 
> instant messaging and presence protocol address.", perhaps we 
> should add a simple example on how to change the defaults w/o 
> removing the existing entries (there are many ways -- some 
> more complex than others -- to do array manipulation)? E.g.:
> 
> // get the myContact object somehow
> // ...
> // change myContact defaults w/o removing the existing 
> entries myContact.impps.unshift({ types: ['home'], value: 
> 'sip:new-default@example.org ' }); myContact.emails.unshift({ 
> types: ['work'], value:  
> 'john.doe@example.org' });
> 

I think something along these lines is inferred. Your code is helpful
but I'm wondering whether we need to include it in the specification
itself?

One further proposal could be to provide a method on ContactField that
allows the users to get and set the default. Interested?

> 4.6.1
> 
> "The way to group the first enumerable ContactProperties 
> attribute provided in the related method. Only the first 
> ContactProperties property provided can be grouped." ECMA-262 
> section 12.6.4 "The for-in Statement" says: "[t]he mechanics 
> and order of enumerating the properties [...] is not 
> specified", thus we cannot rely on the order of the 
> ContactProperties properties as the Note suggests. One 
> solution would be to replace the group attribute with an 
> orderBy attribute which defines the property name according 
> to which to sort. The sort attribute could also be renamed to 
> sortOrder and its value could be case-insensitive.
> 

FWIW, despite the ECMAScript spec, "currently all major browsers loop
over the properties of an object in the order in which they were
defined. Chrome does this as well, except for a couple cases." [2] [3]

Despite this informal interpretation by browser vendors, I do feel that
ContactOptions requires an overhaul. I will propose something to the
list this week along the lines you have suggested above.

Many thanks,

Richard

[1] http://dev.w3.org/geo/api/spec-source.html

[2] http://ejohn.org/blog/javascript-in-chrome/

[3]
http://stackoverflow.com/questions/648139/is-the-order-of-fields-in-a-ja
vascript-object-predicatble-when-looping-through-th/648163#648163

*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered,
changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************



---------------------------------------------------------------------
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 Monday, 11 January 2010 18:59:57 UTC