W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Draft minutes 2009-10-14

From: Robin Berjon <robin@berjon.com>
Date: Thu, 15 Oct 2009 09:34:40 +0200
Message-Id: <13B55AF6-EEB4-41F2-8E55-7C29B74B7E58@berjon.com>
To: public-device-apis@w3.org
Here they are:


And in text:


       [1] http://www.w3.org/

                                - DRAFT -

           Device APIs and Policy Working Group Teleconference

14 Oct 2009


       [2] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0148.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/10/14-dap-irc


           Marco_Marengo, Paddy_Byers, Robin_Berjon, Daniel_Coloma,
           wonsuk, David_Rogers, Dzung_Tran, Ilkka_Oksanen,
           Anssi_Kostiainen, Richard_Tibbett, Marcin_Hanclik,
           WonSuk_Lee, Claes_Nilsson, Kangchan

           Frederick_Hirsch, Niklas_Widell, Dominique_Hazael-Massieux,
           Venezia_Claudio, Steve_Lewontin, Daniel, Coloma

           Robin Berjon

           Bryan Sullivan, Bryan1


      * [4]Topics
          1. [5]Welcome, agenda review, scribe selection
          2. [6]Minutes approval
          3. [7]Editorial Updates
          4. [8]Policy Segment
          5. [9]ISSUE-32
          6. [10]API Segment
          7. [11]AOB
      * [12]Summary of Action Items

    <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


      [13] http://www.w3.org/mid/6CC33B25-9534-4030-8445-F0CC02566944@nokia.com

Editorial Updates

    robin: minutes are approved

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

      [14] http://www.w3.org/TR/dap-api-reqs/

    robin: api requirements should be available tomorrow at the address
    ... 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> [15]http://www.w3.org/WAI/intro/aria.php

      [15] 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

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

    robin: paddy created a new issue


    paddy: question was having a policy governing access to resources,
    how to id the resources portably in ways meaningful to policy
    ... 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


    robin: anything else on APany other business

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

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

Summary of Action Items

    [NEW] ACTION: Paddy to document the output of the prompting
    discussion [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [18]scribe.perl version 1.135
     ([19]CVS log)
     $Date: 2009/10/14 14:37:06 $

      [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [19] http://dev.w3.org/cvsweb/2002/scribe/

Robin Berjon - http://berjon.com/
Received on Thursday, 15 October 2009 07:35:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:12 UTC