Re: [contacts] HTML5 Device integration proposal

On Mon, Jul 5, 2010 at 7:22 PM, James Salsman <jsalsman@talknicer.com>wrote:

> Would it be a good idea to duplicate location in the device element as
> well, so that it may be placed under the same controls as have been
> contemplated in the DAP privacy policies?
>

I'd expect that the HTML5 Device element could support just about any
non-form-based API. For geolocation it could just be:

*<device type="geolocation" onchange="updateLocation(this.data)">*
<script type="text/javascript">
function updateLocation(position) {
    // do something with resulting Position object
}
</script>

I'm concerned about proceeding without an unencumbered privacy policy
> in place, for location, contacts, audio, video, the device's file
> system, and other databases that web apps developers want to use,
> including network selection under multi-homing.


I guess that is the purpose of this month's W3C Privacy Workshop
http://www.w3.org/2010/api-privacy-ws/. From my understanding they will be
looking at ways in which privacy policies can be easily created by service
providers, easily communicated by developers and easily understood by users
- all enforceable at the API level. I think we will all be hoping for some
practical outcomes that we can use :-)

- Richard


>
> On Mon, Jul 5, 2010 at 11:16 AM, Rich Tibbett <rich.tibbett@gmail.com>
> wrote:
> > This is a short and sweet proposal for low-level integration of the DAP
> > Contacts API [1] to the candidate HTML5 Device element [2] being defined
> in
> > WebApps.
> > The rationale for this proposal is that regardless of whether a web page
> > obtains address book data from either the programmatic method defined in
> [1]
> > or a HTMLDeviceElement-based method yet-to-be-fully-clarified in [2] it
> > should be capable of accessing any resulting contact data in a uniform
> way.
> > By providing a DOM-based method in [2], the 'contacts picker' (as
> > informatively described in [1] Appendix A) would be reusable for the
> > HTMLDeviceElement method without requiring that the 'contact search
> > notification' dialog to also be used in this approach. The result is one
> > less click for the user in the DOM-based approach.
> > The proposal for accessing Address Book information from the HTML5 Device
> > element goes like this:
> > <device type=people onchange="successContactFindCallback(this.data)">
> > <script type="text/javascript">
> > // Identical to the example provided in the Contacts API:
> > function successContactFindCallback(contacts) {
> >     // do something with resulting contact objects
> >     for (var i in contacts) alert(contacts[i].displayName);
> >     // ...
> > }
> > </script>
> > where: HTMLDeviceElement.data will always be of type
> > Contact[] whenever HTMLDeviceElement.type=='people'
> > This element would render on a web page similar to the file input element
> > except that it would load the 'contacts picker' on invocation by the
> user.
> > This is notably not a form-based control, though data resulting from this
> > control could be used to populate a web form.
> > Could additional Contact API find() parameters be provided from a web
> page
> > to the 'contacts picker' in the DOM-based approach as follows?
> > <device type=people
> >
> data-params="fields=name,emails;filter=Robert;updatedSince=2010-05-23T00:00:00Z"
> > onchange="successContactFindCallback(this.data)">
> > Any better ideas for the 'data-params' attribute that I used above
> > considering it's not currently a common HTML5Element attribute?  Perhaps
> > this attribute should be added to the HTMLDeviceElement interface in [2]
> or
> > maybe an existing HTMLElement attribute (such as 'accept') could be
> reused
> > for this purpose.
> > Finally, a logistical question: How much of this proposal, if useful, can
> be
> > included in the HTML5 Device document [1] vs. the Contacts API document
> [2]?
> > Any feedback would be much appreciated. I'm just throwing the ball up in
> the
> > air :-)
> >
> > - Richard
> >
> > [1] http://dev.w3.org/2009/dap/contacts/
> > [2] http://dev.w3.org/html5/html-device/
>