- From: Rich Tibbett <rich.tibbett@gmail.com>
- Date: Tue, 1 Jun 2010 18:04:33 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: public-device-apis@w3.org
- Message-ID: <AANLkTilkFRLxK6DBLN1oSW29VuuoIX5ZLvr9UESZLlsq@mail.gmail.com>
Hi Dom, Thanks for pinging me. I updated the spec immediately following the DAP F2F for ACTION-125 although I see that a number of items may still open to discussion. These are: - Filter matching and whether to move to regex-based syntax for partial matching. The spec currently says that matching is lazy (match any and all instances of the provided string). The choice is then the user's on deciding exactly which contact objects (if any) are returned from the resulting 'contacts picker'. I think it's cleaner than getting in to the can'o'worms of regex without denying the user the ultimate choice of what information to share back to the requesting site/page: essentially the filter is an aid/helper for the user to select a specific contact or contacts if the web app knows something about the contact(s) that the user wishes to share (such as first name or phone number). - Role of the serviceId parameter. I'm updating the spec to include 2 well-known serviceId values - 'uicc' (SIM) and 'device' (System). The default behaviour for an unknown/null serviceId has also been included - let the implementation decide on the most suitable storage and let it set the serviceId attribute accordingly. The spec goes on to recommend that for any other storage a conformant implementation should assign a serviceId attribute as a URI. The serviceId attribute is at all times read-only. A serviceId may, for example, act as the REST API root for web-based information providers - an implementation could hook in to the provided serviceId URL to interact with the remote contacts database. I have also created an interpretation of a conformant Contacts Picker UI (attached to this email and based on the find(..) example included in the current Contacts API spec). This completes ACTION-124 (but feedback to tweak the demo UI is welcome). This is, of course, only one interpretation of Contacts-based interaction that the specification enables. I could place this in the current Contacts API draft (to flesh out the non-normative examples provided) but perhaps this would be best placed in a best practices document for implementors. WDYT? Any plans on producing a best practices document as discussed at the DAP F2F in Prague? I ask because I'd like to push the Contact API 'Design Considerations' in there also. Explaining the methodology is good for implementors in a best practice doc but tends to detract from the technical content and testability of the API spec itself. I'll continue to update this spec this week and I'll aim for a strong contendor for publication by Friday. I haven't done so today because I'm experiencing some issues with my CVS access. I'll get this sorted offline in the coming days. I will not be able to attend the teleconference tomorrow but I will read the minutes when I return to my desk and if there are any other items please do discuss them on the mailing list in my absence. Kind regards, Richard On Tue, Jun 1, 2010 at 8:40 AM, Dominique Hazael-Massieux <dom@w3.org>wrote: > Hi Richard, > > Back during the F2F in Prague, we had scheduled to publish an > intermediary draft of the Contacts API with the agreed upon changes [1] > in April, with a target of a Last Call draft in June. > > Obviously, we've missed the April target, which I think makes it > unlikely to go to Last Call this month :) > > That said, I think it would be useful to publish an intermediary draft > as soon as possible — are there any changes discussed at the F2F (or > since) that still need to be brought into the editor draft (re your > ACTION-125)? If so, do you have any estimate as to when you might have > the time to include them in the document? > > Thanks! > > Dom > > 1. > > http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0169/minutes-2010-03-17.html#item03 > >
Attachments
- image/png attachment: contacts_notification.png
- image/png attachment: contacts_picker.png
Received on Tuesday, 1 June 2010 17:05:35 UTC