Re: re-publication of Contacts API

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 UTC