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

RE: [Contacts] couple of comments

From: <richard.tibbett@orange-ftgroup.com>
Date: Mon, 11 Jan 2010 19:09:40 +0100
Message-ID: <3404_1263233381_4B4B6965_3404_32269_1_355A518BC0575547B2A3D6773AAF8EEF7FE499@ftrdmel1>
To: <anssi.kostiainen@nokia.com>, <public-device-apis@w3.org>
Cc: <maxfro@opera.com>
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.
********************************
Received on Monday, 11 January 2010 18:10:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC