Re: re-publication of Contacts API

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
>
>