Re: re-publication of Contacts API

On Wed, Jun 2, 2010 at 9:10 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

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

On the premise of using a lazy matching mechanism I would say that "hazael"
should match "Hazaël" in the resulting contacts picker. It may be good to
define the term 'lazy matching' further in the spec (case-insensitive
matching is already included).

It would be good to discuss ACTION-122 further and see if any changes are
proposed to the spec.


> > 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.
>
>
Right. I'll create a non-normative Appendix to house this stuff as it is
useful but not essential information.

- Richard