Device APIs Working Group Teleconference

19 Sep 2012


See also: IRC log


ccourtney, Josh_Soref, fjh, +25686aabb, Dsr, Alexander_Salas, dtran, SungOk_You, Jungkee, +, Milan_Patel, Giri_Mandyam, richt, Clarke, Cathy, Frederick_Hirsch, Colin_Courtney, Jungkee_Song, Dave_Raggett, Clarke_Stevens, Claes_Nilsson, Dzung_Tran


<trackbot> Date: 19 September 2012

<scribe> Scribe: Josh_Soref

<gmandyam> Giri Mandyam from Qualcomm Innovation Center here - dialing in from (858) area code

<dtran> +Present Dzung_Tran


Josh_Soref: Next week is Yom Kippur

<dsr> You can declare your phone number via the W3C User Search Form https://www.w3.org/Systems/db/userSearch and then click on the contact tab after having found yourself

fjh: are there other people in Josh_Soref 's situation

<dsr> I will be away for next 2 weeks.

<fjh> PING http://lists.w3.org/Archives/Public/public-privacy/2012JulSep/0059.html

fjh: there's a PING call

<fjh> PING is the privacy interest group, tomorrow call will have Dom reviewing 'Permissions on the Web', possible privacy review of WebIntents; I believe Paul Kinlan plans to attend as well as myself

<fjh> to attend you need to join PING

<fjh> I attended an earlier PING call and reviewed DAP privacy work in general

<ccourtney> Josh_Soref: Got it. I'll make sure to change that next time.

Minutes Approval

fjh: we'll defer until next week

Josh_Soref: i sent out a draft
... i'm going to send out a revised version

Pick Contacts Intent

<fjh> Pick Contacts Intent updated, http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0058.html

Jungkee: i updated webidl definitions
... the type of array from Sequence Type
... dictionaries are pass by value
... one topic is search capability
... based on the intent discussion, we lost the extra field
... the extra field was meant to deliver types
... now we want to deliver type in the specific api
... for Pick-Contact/Pick-Media
... the need to request certain fields
... i'd like to hear some opinions about search/filtering fields
... maybe we can use the data field
... but that's defined to deliver the object itself
... maybe we put in extra information fields
... any ideas?

fjh: it seems like there are two issues
... 1. do we need search?
... 2. can extras be used
... I think being able to search makes sense

Jungkee: in the case of pick-contact
... contacts has quite a few fields
... and the client developer may require some number of fields
... explicitly from the services
... filtering capability is kind of necessary

<fjh> josh_soref: at least initially, would rather see the providers manage this, they can design a better UI

<fjh> josh_soref: then we can think about an API

<fjh> josh_soref: there are too many ways to define a contacts database, for example an address field, various types with different semantics, eg. business address vs address

<fjh> josh_soref: thus it isn't clear search will work as expected, depending on assumptions

<fjh> josh_soref: will need to work out patterns over time, then eventually standardize it

<fjh> josh_soref: also bad if request has to include 1,000 fields

<fjh> josh_soref: pick contacts and then fields you want (?)

<richt> +1 to Josh_Soref. Leave search/filtering up to providers initially.

<fjh> josh_soref: josh suggests naviating through contacts

gmandyam: aren't you putting the problem of 1000 fields from the intent invocation
... and into the dialog box

<fjh> josh_soref: case of picking intent provider or not, once picked then service provider can provide search, e.g. facebook does, google does,

<fjh> josh_soref: so good service providers already do this

<fjh> josh_soref: users would prefer seeing familiar sp interface

<fjh> fjh: I could argue that is not aways true if users wish to use multiple services....

<fjh> josh_soref: so lets leave it to the sp

Jungkee: the client developer just want to make some specific request
... the fields that they can specify in filtering property
... is confined to fields already defined in the contacts intent spec
... it's constrained
... 1000 fields isn't going to happen
... it's just a hint to the sp
... if the client has a specific UC

Josh_Soref: Clients will always have to have adaptation code
... for when Providers don't honor their "hints" or fill in fields sufficiently
... by not having hints, Providers are forced to consider users' Data privacy at a field level
... and design a UI to address this
... the Clients are saved from some extra field filling which would be ignored
... either way they [the clients] had to write the adaptation code
... and the Providers don't get led down a path where they just provide all requested fields
... they have to think about and design a privacy conscious UI

fjh: [summarizing]
... pushing the search capabilities to the service provider
... you avoid issues of semantics for the service provider
... you reduce confusion for the user, and increase familiarity for the user
... the flip side is what happens for multiple providers
... or for non web providers

<fjh> fjh: possible confusion for user accessing variety of providers

<fjh> josh_soref: for non-web provider (e.g. local) someone has to write adaptation code, will create UI

<fjh> josh_soref: e.g. for phone, would try to make it close to phone feel

<fjh> josh_soref: would have to consider privacy regardless, so not really different case

<fjh> josh_soref: can address confusion of multiple providers through the use of an aggregator

<fjh> fjh: I thought initially in contacts API we had search to avoid retrieving more information than needed, data minimization

<fjh> josh_soref: regarding only retrieving certain fields, I suggest it is more common to request all, since users want to make sure they get what they need, and not blank fields

fjh: i think we need a CfC on the list
... obviously it simplifies stuff for us
... there's a certain logic to that, they know what matters to people in their domain

richt: i think leaving it to the providers initially is in their interest
... they don't want to give away the farm
... they won't be giving out everything
... if there was an invisible context
... there should be a return nothing
... XXX
... if providers return the same thing, we can later codify that
... providers will want to protect their users

fjh: it has the benefit that there's someone you can sue in court
... by leaving things to the providers

richt: right
... if the api has a bug in it, and it malfunctions, that's bad

fjh: i'm looking to see how to make it a specific thing
... CfC would say we remove extras
... and to remove the search functionality

Josh_Soref: i thought we already removed search
... and we're just saying we're removing field hints

Jungkee: i haven't removed the search field yet

fjh: i'll send out a CfC that does remove search+filter+field-hint
... i think we're agreed
... but since people aren't on the call, i think we should send out to the list

richt: you could define different service types that provide subsets of contact information

<fjh> ACTION: fjh to send CfC for removal of search from Pick Contacts [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action01]

<trackbot> Created ACTION-576 - Send CfC for removal of search from Pick Contacts [on Frederick Hirsch - due 2012-09-26].

richt: so if i'm just looking for "email addresses", that would be the service id
... i expect there to be innovation in that area
... you can have as many service types as you like
... and you request a subset

fjh: that makes sense too

Josh_Soref: +1

fjh: i'll send out the CfC, and we can move pretty fast w/ or w/o a call
... thanks Jungkee , Josh_Soref

Ambient Light Intent

fjh: dougt has created a new draft

<fjh> Latest draft, http://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html

fjh: there were a few clarifying things on the list
... i think we'll publish an update fairly soon
... i guess that's a FPWD
... oh, we already have a FPWD
... so it'll be an update
... i don't think there's anything to discuss today

HTML Media Capture

fjh: we have to move through LC comments

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0050.html

fjh: i don't think we're done w/ shepazu's comments

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0051.html

fjh: i haven't had a chance to go through them

<fjh> LC-2644 possible resolution, http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0079.html

fjh: i think we have a resolution for one

<fjh> "If document scanners and live scanners declaring themselves as cameras is a viable technical solution, it is fine."

Josh_Soref: Camera is a "still image capture device"

fjh: i think that's resolved
... we might need to clarify that somewhere in the doc
... does anyone have any concern?

[ None ]

<fjh> ACTION: fjh to draft text proposal to resolve LC-2644 [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action02]

<trackbot> Created ACTION-577 - Draft text proposal to resolve LC-2644 [on Frederick Hirsch - due 2012-09-26].

Web Intents Addendum

<fjh> http://w3c-test.org/dap/wi-addendum-local-services/

fjh: i think we're waiting on Cathy 's request for changes

Cathy: nothing on my part
... i think Claes is waiting for comments

fjh: i don't think we need to wait for comments before FPWD
... the act of FPWD will invite comments

<fjh> Propose to WebIntents TF to publish FPWD of "Web Intents Addendum - Local Services"

Claes: i think that would be good

<fjh> ACTION: fjh to propose FPWD publication of "Web Intents Addendum - Local Services" on TF [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action03]

<trackbot> Created ACTION-578 - Propose FPWD publication of "Web Intents Addendum - Local Services" on TF [on Frederick Hirsch - due 2012-09-26].

<fjh> fjh: publication of FPWD should solicit comments

RESOLUTION: DAP is ok with a FPWD of Web Intents Addendum - Local Services


<fjh> Please remember to complete the WG questionnaire for the F2F and also the TPAC registration as well as making your travel arrangements.

<fjh> https://www.w3.org/2002/09/wbs/43696/dapf2ftpac2012/ ; http://www.w3.org/2012/10/TPAC/Overview.html#Registration

<fjh> Please suggest topics for DAP F2F agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France

fjh: i think we'll spend a good amount of time on Web Intents
... related, and how to work w/ whatwg
... Web Intents, Pick Contacts, Pick Media
... and HTML MC
... i'd prefer for people to edit the wiki directly
... does anyone have suggestions regarding the F2F?
... it looks like the Media TF will meet
... we might want to suggest they meet on Tuesday
... i think we're required to have a draft agenda 2 weeks before the F2F

dsr: the other thing to do is Observers
... to figure out how many are attending

fjh: to give them permissions

Josh_Soref: and to calculate room size

fjh: please think about the agenda


fjh: i need to resolve/reassign darobin 's

<fjh> ACTION-565?

<trackbot> ACTION-565 -- Josh Soref to propose text for HTML Media Capture to allow for alternative capture device if specified device not available -- due 2012-08-22 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/565

Josh_Soref: if you want to do it
... i think we're on the same page

<fjh> ACTION-568?

<trackbot> ACTION-568 -- Jungkee Song to work with Robin to move darobin to move API Cookbook to w3c space and prepare for publication as W3C FPWD NOTE -- due 2012-08-29 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/568

Jungkee: i spoke with darobin
... he's going to do the action very soon
... i'm waiting for that
... it should happen within a week

<fjh> ACTION-519?

<trackbot> ACTION-519 -- Claes Nilsson to add a proposal for hidden disposition. -- due 2012-08-15 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/519

<fjh> in progress

<fjh> ACTION-572?

<trackbot> ACTION-572 -- Frederick Hirsch to move specs in the home page Roadmap to 'Exploratory Work' section -- due 2012-09-05 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/572

<fjh> close ACTION-572

<trackbot> ACTION-572 Move specs in the home page Roadmap to 'Exploratory Work' section closed


<dtran> Galaxy Nexus has pressure sensor

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: fjh to draft text proposal to resolve LC-2644 [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action02]
[NEW] ACTION: fjh to propose FPWD publication of "Web Intents Addendum - Local Services" on TF [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action03]
[NEW] ACTION: fjh to send CfC for removal of search from Pick Contacts [recorded in http://www.w3.org/2012/09/19-dap-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/09/19 14:53:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Pick-Contact/Pick Contacts Intent/
Succeeded: s|gary: pushing it to user dialog box?||
Succeeded: s/they/they [the clients]/
Succeeded: s/lis/list/
Succeeded: s/fields/field/
Found Scribe: Josh_Soref
Inferring ScribeNick: Josh_Soref
Default Present: ccourtney, Josh_Soref, fjh, +25686aabb, Dsr, Alexander_Salas, dtran, SungOk_You, Jungkee, +, Milan_Patel, Giri_Mandyam, richt, Clarke, Cathy
Present: ccourtney Josh_Soref fjh +25686aabb Dsr Alexander_Salas dtran SungOk_You Jungkee + Milan_Patel Giri_Mandyam richt Clarke Cathy Frederick_Hirsch Colin_Courtney Jungkee_Song Dave_Raggett Clarke_Stevens Claes_Nilsson Dzung_Tran
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0081.html
Found Date: 19 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/19-dap-minutes.html
People with action items: fjh

[End of scribe.perl diagnostic output]