W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: re-publication of Contacts API

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 02 Jun 2010 10:10:56 +0200
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: public-device-apis@w3.org
Message-ID: <1275466256.2133.2394.camel@localhost>
Le mardi 01 juin 2010 à 18:04 +0100, Rich Tibbett a écrit :
> 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).

Sounds good to me; I would probably even go further, and leave the
matching algorithm entirely user-agent dependent, making the search
terms more of a hint than anything else. Even partial matching can be
ill-adapted in some cases; should "hazael" match "Hazaël" for instance?

(this relates to Robin's ACTION-122 BTW)

> - Role of the serviceId parameter. I'm updating the spec to include 2
> well-known serviceId values - 'uicc' (SIM) and 'device' (System).
> [...]

I'll have to look back at this once it it's in the draft, as I recall I
had concerns about this serviceId attribute :) But that probably
shouldn't be a blocker for publication as a simple draft.


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

Rather than putting it as a separate document (esp. one called "best
practices" - that  would be hard to justify given that there hasn't been
much practice in implementing this API yet :), I would suggest moving
the Design Considerations, accompanied with the new screenshots, into a
non-normative Appendix. We can evaluate whether it should go away from
the document at a later stage in the Rec track, I think.

Dom
Received on Wednesday, 2 June 2010 08:11:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT