ISSUE-111: Should (some of the) ContactField objects use URLs rather than free-form strings?

urlInContacts

Should (some of the) ContactField objects use URLs rather than free-form strings?

State:

CLOSED

Product:

Contacts API

Raised by:

Dominique Hazaël-Massieux

Opened on:

2011-06-01

Description:

discussed on June 1st call [1], but originated from previous messages on the list [2,3])
1.
http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/att-0004/minutes-2011-06-01.html#item05
2.
http://lists.w3.org/Archives/Public/public-device-apis/2011May/0026.html
3.
http://lists.w3.org/Archives/Public/public-device-apis/2011May/0032.html


The current Contacts API has 5 properties that are defined in as list of
objects of a generic ContactField Interface:
http://dev.w3.org/2009/dap/contacts/#contactfield-interface

These properties are phoneNumbers, emails, ims (instant messaging),
photos, and urls.

All of these properties can be cast into URIs:
- phone as tel:+1-555-5555-5555 (and sip:voip@example.org, skype:...,
etc)
- emails as mailto:dom@example.org
- ims as aim:foobar (although I'm not sure there are URI schemes for
all, nor if the existing ones are properly registered or not)
- photos as http://example.org/am-i-hot-or-not or
data:image/jpg;123ACCD33433...
- urls as themselves

Given this, I've been arguing that instead of saying that the "value"
property of the ContactField interface is a free-form DOMString, we
should ask implementations to expose these data as URLs.

Richard and Robin have argued that it wouldn't be possible in every case
to turn user-entered data into URLs.

That's probably true for ims and phone numbers:
* ims, because the type of instant messaging is not always recorded with
the data, and when it is, it's not necessarily in a way that can lend to
be turned into a URI scheme (when one exists)
* phone numbers, because they need to be complete enough to be turned
into URIs (e.g. they need the international calling code?), and they may
also contain non phone number information (e.g. manually indicated
extension number)

It seems to me that these concerns don't apply to emails, photos, and
urls (!).

So, assuming that we agree that exposing these data as URLs as much as
possible is the right thing to do, I think the following options exist:
* we complete ContactField with a url property that contains the same
data as the value field, but url-transformed to the best ability of the
user agent (or null if it didn't manage)

* we don't try to push for converting phoneNumbers and ims into URLs,
and so we create a separate interface for emails, photos and urls, à la
interface ContactFieldUrl {
attribute DOMString? type;
attribute DOMString? url;
attribute boolean pref;
};

(an alternative is to use the URL interface as the type of the url
field, provided the path toward standardizing such an interface exists,
cf my action-402 and my message
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0778.html
)

Dom

Related Actions Items:

No related actions

Related emails:

1. Re: Re: Should (some of the) ContactField objects use URLs rather than free-form strings? ( LC-2514) (from frederick.hirsch@nokia.com on 2011-07-19)
2. Re: Should (some of the) ContactField objects use URLs rather than free-form strings? (from dom@w3.org on 2011-06-08)
3. Re: Should (some of the) ContactField objects use URLs rather than free-form strings? (from dom@w3.org on 2011-06-01)
4. ISSUE-111: Should (some of the) ContactField objects use URLs rather than free-form strings? (from sysbot+tracker@w3.org on 2011-06-01)

Related notes:

Display change log