Device APIs and Policy Working Group Teleconference -- 14 Oct 2009

<trackbot> Date: 14 October 2009

<darobin> tlr: Zakim is buggy it seems...

<tlr> darobin, known problem, we'll need to deal with it

<darobin> ok, cool

<dtran> +dtran

<dtran> dtran is Dzung_Tran

<arve_> I am on the call at least

<darobin> arve_, it's a bug

<darobin> we need an "RRSAgent who's here?"

<darobin> can anyone hear me?

<paddy> I can hear

<darobin> arve_, are you on the call?

<darobin> Scribe: Bryan Sullivan

<darobin> ScribeNick: Bryan

Welcome, agenda review, scribe selection

tlr: tpac plans for a privacy related panel, what does it mean to be privacy aware

<arve_> whoever got on last needs to mute

<drogersuk> great, white noise

<tlr> *ARGH*

<darobin> bloody hell

<drogersuk> will dial back in when you are sorted

tlr: the scope of policy related work, very broadly, to drill down on the intellectual side of the topic
... just calling to attention the plans to have a discussion

Minutes approval

<darobin> http://www.w3.org/mid/6CC33B25-9534-4030-8445-F0CC02566944@nokia.com

Editorial Updates

robin: minutes are approved

<darobin> http://www.w3.org/TR/dap-api-reqs/

robin: api requirements should be available tomorrow at the address shown
... any other edits made last week?
... none so far

Policy Segment

robin: some discussions this week about prompting, any comments on where the discussion is and next steps

paddy: a wide range of starkly differing views. prompting is inescapapable given the wide range of apps expected, and unfamiliarity with the app, and the need to make decisions

<tlr> agreement: "it's difficult"

paddy: good questions about when prompts should occur, e.g. re lifecycle and obstrusiveness
... seems agreement on modality, and that we should stay away from user experience proscription
... but only concrete conclusion is the non-modal prompt expectation

richard: agrees, non-modal is better. we should use the term dialog instead of prompt. the concept of user opt-in should be defined.
... user needs to have an opt-in option, but before that the user should expect prompts. Ian made a good comment, about difficulty addressing all cases. But implicit prompting is usedful, e.g. based upon platform filesystem functions.

thomas: leaning the same direction; we know a lot that doesn't work, some that do work, e.g. re implicit concepts such as pushing a button on a camera. non-modalness is important.

<Zakim> darobin, you wanted to talk about UI terminology

thomas: question about what info is available to the user-agent about the user's intent

<darobin> http://www.w3.org/WAI/intro/aria.php

robin: terminonology may consider aria for terminology, see link

<paddy> I can do that

robin: hearing support for the general ideas, would someone write up the agreement
... paddy has the action to do it

<darobin> ACTION: Paddy to document the output of the prompting discussion [recorded in http://www.w3.org/2009/10/14-dap-minutes.html#action01]

<trackbot> Created ACTION-28 - Document the output of the prompting discussion [on Paddy Byers - due 2009-10-21].

robin: paddy created a new issue

ISSUE-32

paddy: question was having a policy governing access to resources, how to id the resources portably in ways meaningful to policy authors
... have written down some thoughts and terminology to get the discussion started, e.g. "device capability" which is definable independent of the API's used to get access to the capability
... next interfaces, which are directly related to the API's accessing the resources
... next the "feature" which are the API functional capabilities
... we have had discussion on using IRI to id the resources
... 2nd question is whether need to id the capabilities themselves, to allow API-independent policies

<tlr> excellent point

paddy: so access to a capability is controllable independent of the API, which is what BONDI supports
... propose to discuss / validate the use cases and decide how to address this for DAP policy

robin: any reactions now?
... now this is started, input is requested and discussion. unsure how the policy docs will be organized, but we could paste some of this into a document for review. we will discuss this when Fredric is here.
... anything else on policy?

API Segment

robin: item discussed is where do we want the API to hang off of. some inputs, e.g. we may not want to define it immediately.
... so I recommend to wait for more API's to be defined then return to the hanging off discussion

<Bryan1> scribenick bryan1

<darobin> arve: only just got back, will look into FS ASAP

<Bryan1> scribe: Bryan1

<darobin> ScribeNick: Bryan1

<darobin> robin: will continue contacts discussion on list

<darobin> richt: will contact robin offline to start putting things inside the calendar spc

robin: a lot of discussion on scoping, sensors, etc. anything to discuss now?
... will wait for the concrete input and take it from there

<darobin> richt: I will join the editorial pool for APIs

richard: will join the editor pool

AOB

robin: anything else on APany other business

richard: "meta-discussion" on the list. any guidelines for list discussion?

robin: discussion about how to conduct discussion. we will make easier progress if we edit and them consider the edits, rather than discuss too long up-front
... sometimes its better to dive in and assess where we are periodically
... it would be good to have some concrete work done before the F2F, and take a step back at the F2F

david: agree, key concern raised by me is that the charter has 10 API's. we need to concentrate on those. new ideas are expected, but the three inputs so far focus on a set of API's
... being royalty-free, we should focus on them

robin: there is some grey area due to vagueness in the charter, with wiggle room expected. but we need to wait for concrete proposals and consider IPR issues as they arise
... AOB?

<darobin> thanks Bryan

<darobin> RRSAgent: make minutes

- DRAFT -

Device APIs and Policy Working Group Teleconference

14 Oct 2009

Attendees

Contents