- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 01 Jun 2011 18:52:22 +0200
- To: Device APIs and Policy Working Group WG <public-device-apis@w3.org>
Le mercredi 01 juin 2011 à 14:57 +0000, Device APIs and Policy Working Group Issue Tracker a écrit : > ISSUE-111: Should (some of the) ContactField objects use URLs rather than free-form strings? > http://www.w3.org/2009/dap/track/issues/111 A bit more context on this issue (which we discussed on today's call [1] but originated from previous messages on the list [2,3]): 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 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
Received on Wednesday, 1 June 2011 16:52:38 UTC