Re: [contacts] HTML Contact Sharing

On Mon, Sep 27, 2010 at 11:26 AM, Nilsson, Claes1 <
Claes1.Nilsson@sonyericsson.com> wrote:

>  Hi Richard,
>
>
>
> Generally I like the idea of creating simple APIs based on HTML elements.
> As far as I understand your intention is to provide a simpler alternative
> for developers than the JS Contacts API. This HTML API will be usable for
> some use cases.
>
>
>
> Comparing with the Firefox demo implementation of the JS API I assume that
> the use case covered by the HTML Contact API is the “Use Contacts to
> Personalize This Page” case.
>

Right.


>  The “e-mail autocompletion” use cases wouldn’t be possible to implement
> with the “Device-element” as a “selector”-button is required. Correct?
>

Autocompletion is a feature of the implementation. It could be provided by a
UA on top of a page without the page itself needing to request this feature.
i.e. it doesn't need to be specified in an API IMO.


>
>
> Furthermore, in your example in Appendix A I miss user consent for
> approving the operation.
>

Consent is implicit. By selecting contacts to share consent is given in the
same way as uploading a file works in the file picker. If I don't want to
share I don't click to share or click cancel when the contacts UI widget
appears.

Thanks,

Rich


>
>
> *From:* public-device-apis-request@w3.org [mailto:
> public-device-apis-request@w3.org] *On Behalf Of *Rich Tibbett
> *Sent:* den 22 september 2010 02:20
> *To:* public-device-apis@w3.org
> *Subject:* [contacts] HTML Contact Sharing
>
>
>
> I've uploaded a new proposal that defines HTML enhancements to provide
> access to a user's address book data. The first draft can be viewed here:
>
>
>
>   http://dev.w3.org/2009/dap/contacts/HTML.html
>
>
>
> This draft is up for discussion - it does not assume consensus on the
> material at this point.
>
>
>
> The proposal is based on HTML Device [1] and reuses the basic security and
> privacy principles and existing low-level parts of the programmatic Contacts
> API [2] to provide address book data to a web application.
>
>
>
> We chose to build atop of the device element for a number of reasons,
> primarily because:
>
>
>
> - unknown/unimplemented HTML input elements degrade to a text field which
> isn't an intuitive user experience if the feature is not supported in the
> user's current browser.
>
>
>
> - the HTML device element is not a form-based element. That isn't the
> primary intention of it's use to obtain contact information. Having said
> that ...
>
>
>
> - the HTML device element's data attribute can be serialized quite nicely
> (in a JSON.stringify like manner) for transmission via web forms if it
> needed to be and then deserialized (in a JSON.parse like manner) at the
> other end as required. Whether the device element could/should provide
> serialization guidelines is a matter for the WHATWG to decide in [1]. (in
> the HTML Contact Sharing spec a note has been added to this effect). For
> example, the device element's value attribute could be set to the
> stringified value of the data attribute to allow for standard web form
> submission and parsing on the server-side.
>
>
>
> This proposal is an early draft and will be developed going forward.
>
>
>
> The intention is for both the programmatic model in [2] and the HTML-based
> model to co-exist within a conforming user agent, allowing a web developer
> to choose the most suitable mechanism according to their application's needs
> and to allow either model to function with the aid of a common user
> interface/experience, contact storage and format.
>
>
>
> All feedback is welcome and will be taken onboard in order to create the
> most compelling integration model we can. As always,
>
>
>
> - Rich
>
>
>
> [1] http://dev.w3.org/html5/html-device/
>
>
>
> [2] http://dev.w3.org/2009/dap/contacts/Overview.html
>
>
>
>
>