RE: [ContactsAPI][PREF] Re: Contacts API and W3C SysApps

Hi,

If I understand correctly, your proposal is to use the following prototype:
attribute integer pref;

and document that the value must be in the range [1-100], mostly as per vCard v4 format. I say 'mostly' because it may be omitted in vCard format (which would indicate lowest preference) so this would probably translate into making the attribute nullable.

The issue is that this somehow conflicts with your proposal:
"we can define it to be the equivalent of a boolean by defining 0 to mean no preference, and 1 to mean
'preferred'."

0 is not in the allowed range. Also, while the type is forward compatible with vCard v4, the behavior isn't. As per vCard, the lowest the integer, the higher the level of preference is.

I see 2 alternatives:
- Follow strictly vCard v4 and use the following prototype: (attribute unsigned short? pref). Define range as [1-100] and null as the lowest level of preference.
- Simply use a boolean

I still prefer the boolean as this is *much* simpler for the developer. Also, as you said, there is currently no user interface using the preference level and having a boolean is sufficient for current use cases.

I'm also not in favor of using an "integer" type and document that it behaves like a boolean as I don't think it would look good in a specification.

Kr,
Christophe DUMEZ.

________________________________________
From: Tantek Çelik [tantek@cs.stanford.edu]
Sent: Tuesday, April 09, 2013 02:48
To: EDUARDO FULLEA CARRERA
Cc: dev-webapi@lists.mozilla.org; JOSE MANUEL CANTERA FONSECA; public-sysapps@w3.org; Gregor Wagner
Subject: [ContactsAPI][PREF] Re: Contacts API and W3C SysApps

On Fri, Mar 22, 2013 at 5:41 AM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
> [...]
>
> I wanted to have your view on some topics, which are under discussion in W3C SysApps:
>
> -PREF: Firefox OS Contacts API is aligned with vCard 3 as to how it indicates the preferred tel, email, adr... , i.e. by adding "PREF" in the "TYPE" parameter. vCard 4 changes the paradigm by including a new parameter "PREF" whose value is an integer between 1 and 100, to indicate the level of preference. This "PREF" parameter applies to a much wider range of contact data fields. There is a proposal [3] to change those parameters that can have the "PREF" parameter as per vCard 4 to ContactField[] type (from DOMString[]), and it is being discussed whether we should define a boolean pref attribute (it is this way in the Pick contacts Intent) or assume the first element in the array is the preferred one.


The notion of "PREF" in vCard has certainly been challenging.

As you noted, the PREF feature has changed from a type value in vCard3
to a parameter with integer value 1-100 in vCard4.

In practice, the devices that implement a notion of a "preferred" or
favorite phone number for a contact only permit one (iOS, Android),
and then do import/export that preference using the vCard3 PREF as
type value functionality. This is based on our own testing of the user
interfaces of those devices and analysis of their vCard output.

There are no implementations of the vCard4 PREF as parameter as far as
I know. If you know of any vCard4 PREF parameter implementations,
please provide them (URLs, screenshots).

The vCard4 PREF integer value 1-100 is meant to reflect a rough
ordering of preference, e.g. if theoretically a user was to assign a
different level of preference to different phone numbers for a
contact.

I don't know of ANY address book interfaces that provide this
functionality in their user interface (if you do, please provide
them). I don't even know of any discussions to implement such
functionality, thus I'm not sure why the 1-100 range was added to
vCard4.

However, the use of TYPE for PREF is certainly a bit awkward as
mentioned in the email you cited. I believe that was part of the
reasoning for the change in vCard4.

It would be reasonable, and potentially more forward compatible with
vCard4 to separate PREF into another property "pref" separate from
"type", and set it to be an integer, noting that it has the same range
as defined in vCard4.

Since there are no 1-100 preference user interfaces (nor even any
rumors of such), for now we can define it to be the equivalent of a
boolean by defining 0 to mean no preference, and 1 to mean
"preferred". This would also permit implementations to maintain
backward compatible vCard3 exports by treating a pref:1 value as
meaning put "PREF" among the types exported for this contact.

Thus per your raising this, I've added "pref" to ContactField and
ContactAddress and defined it with those limitations.

https://wiki.mozilla.org/ContactsAPI#API

Thanks for bringing up this issue around PREF. Let's see if we can
make this addition work.

Tantek

Received on Thursday, 18 April 2013 08:40:19 UTC