W3C

Device APIs and Policy Working Group Teleconference

16 Mar 2011

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, BJ_Kim, Bo_Chen, Dominique_Hazael-Massieux, Dong-Young_Lee, DongHyun_Kang, Frederick_Hirsch, Gyubong_Oh, Jun_Liao, Kangchan_Lee, Kyung-Tak_Lee, Laszlo_Gombos, Marco_Marengo, Minkyo_in, Robin_Berjon, Soonbo_Han, Soonho_Lee, Wonsuk_Lee, bryan_sullivan, sungok_you
Regrets
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
bryan, bryan_sullivan, dom, dom_

Contents


<trackbot> Date: 16 March 2011

<soonho> Sorry for not attending meeting in this morning.

<soonho> I will be there afternoon.

<fjh> trackbot-ng, start telecon

<trackbot> Meeting: Device APIs and Policy Working Group Teleconference

<trackbot> Date: 16 March 2011

<fjh> ScribeNick: bryan

<fjh> ScribeNick: bryan_sullivan

Admin

<AnssiK> yes

<Suresh> Can we swap the morning and afternoon items in today's agenda?

<dom> Suresh, which items specifically would you like to switch?

<fjh> agenda bashing...

sysinfo and sensors

bryan: is this discussion in context of breaking sysinfo into pieces?

<dom> Bryan: 1st question: are we tackling this in context of new strategy for sysinfo with breaking it apart?

dom: where are we going and how

<dom> SysInfo editors draft

<Suresh> Did we talk about a vocabulary approach, yesterday?

<fjh> http://dev.w3.org/2009/dap/system-info/#system-properties

<dom> we did talk about how sysinfo relates to vocabulary-based approaches

bryan: what are the key functional blocks to consider as discrete APIs?
... how do the info access methods also influence the split?

<Suresh> To me it would be good to split the properties into static (display size, etc) and dynamic (connecttivity, etc)

dom: there are two parts, accessing device characteristics and monitoring dynamic properties

<Suresh> For static properties, we could define a very simple getPropXX () type API and for dynamic APIs decide how we want to proceed

<AnssiK> the current SystemInfo API draft is almost as extensive as /proc (procfs) in UNIX-like OSs

bryan: are the properties to be split per static and dynamic, or by the functional group e.g. connection info

<AnssiK> cf. http://en.wikipedia.org/wiki/Procfs

dom: the first step is to see what can be split out, e.g. connection info, and get editor volunteers
... suggestion to dive into the blocks, starting with the network info. this should be split out into a spec of its own

bryan: capabilities and status?

<dom> Rich's proposal for simple Network API

<AnssiK> +1 for the Network

dom: the next step is to find an editor for the network info API

<lgombos> I plan to take an iteration on the network part

<AnssiK> Battery would be another, which IMHO should not have privacy issues

<dom> navigator.connection in Android

<Suresh> +1 to Rich's proposal

dom: for the network API, richt made a proposal for the network API

<Suresh> i mean we could adopt a similar style to most of the sys info properties

dom: laslo or suresh, do you want to take this on?

<dom> ACTION: Suresh to provide first draft of Network Connection API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action01]

<trackbot> Created ACTION-357 - Provide first draft of Network Connection API [on Suresh Chitturi - due 2011-03-23].

suresh: will take on the network info API

dom: next, anssi mentioned that battery was likely simple enough re privacy and is useful. we don't have a concrete proposal, but the current content in sysinfo can be used as a start

<dom> Battery status

<dom> ACTION: Anssi to provide first editors draft of a Battery status API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action02]

<trackbot> Created ACTION-358 - Provide first editors draft of a Battery status API [on Anssi Kostiainen - due 2011-03-23].

dom: next was the thermometer, we could put this on the back burner

darobin: ok to put more things on the back burner

<dom> ACTION-358: Web Performance WG was interested on battery status — probably need coordination

<trackbot> ACTION-358 Provide first editors draft of a Battery status API notes added

<Suresh> CPU is something device vendors like to keep it to themselves

<dom> CPU is candidate for backburnering

dom: next is CPU, it is unsure whether there are strong use cases for it; could be related to performance, e.g. the Web performance group is focused on battery impacts

<AnssiK> https://developer.mozilla.org/en/DOM/window.navigator.oscpu

dom: for the sensors, we have the question of a generic sensor API. Anssi sent something about what is available in android

<AnssiK> https://developer.mozilla.org/en/DOM/window.navigator.platform

anssik: not me

bryan: I can take on the sensors, but need to know what the plan is for a generic API for this

dom: sysinfo as it exists could be a start

bryan: i can put things in documents but I am not necessarily the technical SME

<dom> ACTION: Bryan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action03]

<trackbot> Created ACTION-359 - Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [on Bryan Sullivan - due 2011-03-23].

<AnssiK> navigator.platform and navigator.oscpu expose CPU-related information already today, works in Moz, Chrome, Saf at least

<AnssiK> what I'm not sure is if developers are using that information

dom: most of the other things are about static properties of the device, most re privacy have abilities re fingerprinting (building a unique identifier based upon device capabilities)

<Suresh> Anssi, but that is only the OS information not info such frequency, processor info, etc

dom: we could start with considering which are most useful
... suresh, are the static properties e.g. cameras microphones etc of interest

suresh: can take on those

<dom> ACTION: Suresh to see at possibilities of APIs for access to device characteristics [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action04]

<trackbot> Created ACTION-360 - See at possibilities of APIs for access to device characteristics [on Suresh Chitturi - due 2011-03-23].

<Suresh> I assume device characteristics are 'read-only'?

bryan: should we package the dynamic I/O APIs as a package?

dom: we should consider that for each feature we want to make available rather than in the abstract

<AnssiK> I heard Bryan or Suresh say something about screen related props, for existing ones, see: http://www.quirksmode.org/dom/w3c_cssom.html

<AnssiK> CSS OM exposes much information that is useful for developers, such as the dimensions of the viewport

<dom> ACTION: Bryan to provide use cases for device characteristics access [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action05]

<trackbot> Created ACTION-361 - Provide use cases for device characteristics access [on Bryan Sullivan - due 2011-03-23].

<Zakim> AnssiK, you wanted to ask do we have a use case that is not fulfilled with the existing platform and oscpu properties on the navigator and to clarify the Screen part

bryan: I will look into the dynamic I/O properties and provide some input, as I think these are related in value to some of the sensor properties, not in terms of a common API but just to help focus what we repackage in the new APIs

dom: CSSOM addresses a number of important characteristics from the dsplay

bryan: would CSSOM provide a pattern for audio?

dom: no, mostly for display characteristics
... that covers a first plan for sysinfo

bryan: what about storage?

dom: proposed work in webapps might cover that

darobin: unsure whether it covers all of it

<dom> Quota API discussion in WebApps

dom: suggest not to work on this given overlap with the work in webapps e.g. with filesystem

<dom> dom: probably covers most of what would be useful for storage

bryan: conceptually this is in the same ballpark as filesystem operations, e.g. to see the size of a filesystem

kangchan: the use case is very helpful to understand the recommendation, in Korea there are many projects e.g. for n-screen and mobile cloud computing, and sysinfo is unique in the world providing the access to this info. We can look at the use cases and provide additional input.

<dom> ACTION: Kangchan to provide use cases for sysinfo-like features [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action06]

<trackbot> Created ACTION-362 - Provide use cases for sysinfo-like features [on Kangchan Lee - due 2011-03-23].

messaging

<Zakim> Suresh, you wanted to clarify the change in direction for Messaging

<darobin> Dom's Messaging proposal

suresh: missed last week's discussion, if the group has agreed to simplify this, what is it based upon?

<Suresh> We clearly say in the scope that the API complements the URI schemes, so this is not competing with URI schemes

dom: the discussion last week was based upon earlier discussion that this is related to what can be done with URI schemes

<dom> dom: the latest proposal I sent for messaging is feature-equivalent to the draft we have currently published as working draft

<Suresh> Super simplification would not allow us to extend in the future if we were to add folder management, search, etc.

<Suresh> But is there a real concern with the current API? Why don't wait for some time to see if there are real issues with implementing as it is

dom: re extensbility, we can consider more and more advanced features separately, but the majority of send message is covered by the URI scheme proposal. Creating wrappers around URI based methods can also fill the gaps.

<Suresh> we also talked about the need to separate the design for different messaging technology and ease of use...

dom: the previous proposal is not integrated well into the Web architecture
... the two existing proposals are mostly feature equivalent

<Suresh> This is the same analogy we have between using HTML Media Capture and Camera

bryan: the other use cases e.g. read/receive are not in the current API anyway, and can be considered for future work

<Suresh> the point i was making was can we have the two models co-exist, URI schemes and a detailed programtic style API

dom: implementers don't want to develop duplicate features
... the stream API is significantly different from HTML media capture
... even if we do consider a programmatic API eventually, that doesn't mean we need to start with it

<Suresh> From ease of use, developers would want to be able to set properties than creating a URL to populate them

dom: a start may be to update the current draft with the new proposal, and call for feedback before moving forward
... having an interface to build messages is a convenience function

darobin: libraries can do that

<Suresh> relying on libaries is not the same as having a standard API

<Suresh> implemented in the browser....

dom: there are good reasons on both sides, let's put the two proposals on the table

<dom> PROPOSED RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)

<darobin> +1

<Suresh> perhaps as you suggest we should have a call for implementations

<dom> RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors)

<dom> ACTION: Dom to see with Maria on how to proceed for updated messaging api draft [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action07]

<trackbot> Created ACTION-363 - See with Maria on how to proceed for updated messaging api draft [on Dominique Hazaël-Massieux - due 2011-03-23].

<Suresh> just to summarize, we would present both the proposals and ask for feedback right>

<dom> indeed, suresh

<Suresh> thanks!

<dom> ??P2 is DAPWG

<Suresh> i will be here until noon session

feature permissions

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0012.html

anssik: the feature permissions spec is being produced by web notiifications group

<AnssiK> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html

anssik: the deliverable is proposed to be moved to DAP

<lgombos> I reached John Gregg and touch based on the spec

<AnssiK> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html

anssik: I have done some investigation and as demo that implements this with a usable interface

<lgombos> John Gregg has no particular plan to advance the spec for the needs that the WebNotification group has

anssik: the demo should run in any browser; open the link and click the run buttons which will execute the code and show an information bar

<AnssiK> http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html#changes

anssik: some changes have been proposed to the DAP spec based upon the investigation
... suggest to use this demo to evaluate whether this is a good idea to decouple the permissions from the API invocations; this is just one way to implement the UI, e.g. from usability point of view, e.g. a drag and drop API from the chrome to the page. Constrained devices would need other UI approaches.

<darobin> +10 on prototypes

dom: this is a good way to consider our motivation to do this work
... this could be useful for other specs outside DAP, e.g. geolocation, some APIs in webapps etc

<dom> http://dev.w3.org/2009/dap/features/

dom: if you can bring in the Feature Permissions spec and propose changes based upon the investigation, that would be a start

<lgombos> dom: I think we should merge the two

dom: a question is the relationship to the current API perms draft

lgombos: I have looked at this and we should merge the two specs - there are a few APIs with valid scope - we should consider what other APIs would possibly be in scope

dom: first we need to get an editors draft in DAP space integrate anssi's comments, and the APIs in scope, and then go to FPWD of Permissions or contact the other groups to let them know we have this work and a prototype, so see if they are interested. The first step is to take ownership of the spec.

logombos: will take on the spec merging task

<Suresh> Contacts/Calendar? but we may need Rich..

<AnssiK> I'm happy to help Laszlo with editing Feat Perms

success criteria

<fjh> suresh expressed concern about chartering limiting to browser context rather than also allowing widgets

suresh: we left off where my comment was that the success criteria based upon the default browser model is too restrictive; we should avoid discussions re whether an approach will not work in the browser context but consider it more broadly, e.g. a policy framework can enable the apps to run the same in a browser or widget context

fjh: unclear about the reference to framework - our rationales were discussed e.g. avoiding plugins - our result was that this does not preclude widgets as long as plugins were not involved

dom: the current charter references the browser context as the main reference point

<Suresh> thanks dom

darobin: everything that works in a browser should work in a widget, but the converse is not true

dom: a concrete example is e.g. we discussed message reading as out of scope as its difficult to see how to implement this in a browser context due to security

<Suresh> replacing the current statement with "APIs that can be demonstrated

<Suresh> without the need of a specialized policy framework will be released" is a good

<Suresh> alternative to indicate that the APIs will be demonstrated using the web

<Suresh> runtime only and not with the assumption of an underlying policy framewrok

<Suresh> which appeared to be the main concern from browser vendors

fjh: as rechartering we are increasing number of deliverables, and will have enough work delivering, might not be wise to add more

<darobin> "without the need of a specialised policy framework" doesn't really help — it needs to also be safe

<darobin> and if it's safe and works without policy — then it works in a browser

dom: what we have heard from browser vendors is that they object to working on things that don't work in the open web

suresh: we need to understand the "open web" and what works in different contexts more clearly
... I would rather that we stay silent or generic on the context

darobin: it is generic, we need APIs that are safe in an untrusted environment

dom: a main hypothesis is that if it works in the browser it should work in other contexts

<dom> Suresh, are you trying to make it so that the group scope included non-browsers-compatible APIs, or are you trying to clarify that our APIs will also work beyond the browser context?

dom: given the group's current progress, we should not expand the charter scope

suresh: do we expect tests to demonstrate ability to use the APIs in both browser and widget contexts?
... the discussions that are concerning are those e.g. saving contacts not having a simple way to represent in the browser context, which unecessarily limit the implementation choices

dom: the concerns about usability and security are constraints on the design process, which needs to verify whether things are really usable and safe

suresh: how do we capture these objectives in the charter, and keep the door open to flexibility in API design?

dom: unless we can prove it works in a browser context, we should not work on it
... there are a number of criteria to consider, the best way to prove something works is to provide a prototype
... the intent of the charter scope is to limit meta discussions
... re including widgets in the charter, we have made some efforts to remove it to prevent misconceptions, but new text can be proposed on the list

suresh: the issue seemed to be more with the policy framework than widgets
... my proposal was to say e.g. if the API is designed to run without a policy framework, it passes the criteria
... is that something that can be in the success criteria?

bryan: could we rephrase this as "installable web applications" instead of widgets, to be more generic?

suresh: does the success criteria affect also the design of the API?

dom: the difficulty we have is to convince browser vendors that the DAP APIs are important to them. We would live with the current criteria in the charter and consider the results on an API by API basis e.g. what contexts are supported and how the success criteria is met during CR

<Suresh> "However, this does not preclude the APIs to be demonstrated in Widgets or Installed environments"

suresh: we should have a statement re "the intent is not to preclude..."

darobin: the restrictions are focused around ensuring the APIs work in a Web context

dom: will add something to the charter based upon Suresh's proposals, e.g. referencing "not precluding support for installable web applications".

security

darobin: where is content security policy going?

<darobin> Content Security Policy

dom: this is a mozilla-led spec intended to limit XSS attack, enabling external website resources to be used safely
... robin asked where this is going - a charter for "Web Applications Security" was sent to the AC a year ago - it's delayed to find a chair and determine interest
... this included CORS and UMP

darobin: our work may include a "COW" document "Characterization of the Open Web" (what are the properties that define the open web) - as a way to be clear about our scope critera

dom: we could throw some ideas on the wiki to see what sticks

<darobin> ACTION: Robin to get the COW started [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action08]

<trackbot> Created ACTION-364 - Get the COW started [on Robin Berjon - due 2011-03-23].

<darobin> ACTION: Frederick to help raise the COW [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action09]

<trackbot> Created ACTION-365 - Help raise the COW [on Frederick Hirsch - due 2011-03-23].

bryan: this would include security approaches, right?

darobin: yes, trust and security

bryan: this will be important to help us find the way forward on security, what is being provided by other groups, and how what we have drafted already (e.g. feature permissions) fits in an "open web" model as compared to a widget model

testing

<dom> ACTION-298?

<trackbot> ACTION-298 -- Dominique Hazaël-Massieux to work with rich on test-enabling the contacts API -- due 2011-03-09 -- OPEN

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

darobin: we need to test contacts soon

<fjh> close ACTION-348

<trackbot> ACTION-348 Send concrete proposal for navigator.sendMessage with URI scheme closed

bryan: what basis for framework and examples wll be used to start?

dom: we earlier agreed to use the Webapps javascript framework as used in the HTML tests, XHR, etc

<fjh> DAP wiki for testing , including framework -> http://www.w3.org/2009/dap/wiki/Testing

dom: one struggle will be defining a test environment e.g. due to dependency upon underlying data, which may require loading of fake data

<fjh> Dom is planning on testing related to contacts, so is Rich, plan to make call for contributions later

<AnssiK> I presented the QUnit-based approach to unit testing at the last f2f

<AnssiK> http://www.w3.org/2009/dap/wiki/Testing#Notes_on_testing_framework_used_by_Phonegap

fjh: what about HTML media capture?

<AnssiK> the group decided to align with the WebApps WG harness instead

dom: we are stuck

HTML media capture

<AnssiK> so I have not made further progress on the unit testing front after that

darobin: the "role" attribute is intended for assistive technologies and not for other purposes - we need to find another approach

<AnssiK> I believe jgraham of Opera is the original author of the WebApps harness contributed to W3C

<AnssiK> but I'm not 100% sure, Opera participants probably know the best

<dom> ACTION: Dom to restart with HTML WG on getting new attribute for HTML Media Capture [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action10]

<trackbot> Created ACTION-366 - Restart with HTML WG on getting new attribute for HTML Media Capture [on Dominique Hazaël-Massieux - due 2011-03-23].

fjh: we need to update the draft and can then go to last call

darobin: better to put out a new WD first
... a draft will help get feedback from the HTML WG

<dom> ACTION: Dom to update HTML Media Capture with new attribute [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action11]

<trackbot> Created ACTION-367 - Update HTML Media Capture with new attribute [on Dominique Hazaël-Massieux - due 2011-03-23].

<dom> ACTION-366: todo after ACTION-367

<trackbot> ACTION-366 Restart with HTML WG on getting new attribute for HTML Media Capture notes added

<fjh> plan is to update HTML Media capture, then publish new WD, get feedback, then consider last call

<dom> http://www.w3.org/TR/test-methodology/

bryan: what are the steps in getting ready for tests?

darobin: there is a methodology

<dom> linked from http://www.w3.org/2009/dap/wiki/Testing

dom: the the best way is to identify test assertions and tests to cover them

fjh: the spec editors need to use the document markup conventions supporting the test assertions

dom: it's more important to just get started on creating tests, and then progress through an interative process

fjh: the test assertions and tests are essential to move spec further in the process...

<dom> Web Tracking and User Privacy Workshop, April 28-29

<dom> [we're breaking until 2pm local time]

<dom> AnssiK, we'll be using 26631 as a conf code; I'm not sure why the regular one doesn't work

<dom> ScribeNick: dom

Contacts API

-> http://dev.w3.org/2009/dap/contacts/ Contacts API Editors draft

Frederick: actually, let's start with Gallery

Gallery API

ACTION-314?

<trackbot> ACTION-314 -- Anssi Kostiainen to react on media gallery use cases -- due 2010-12-15 -- OPEN

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

<fjh> http://dev.w3.org/2009/dap/gallery/

Anssi: should look at use cases before deciding to work on it
... also need to check how much priority this should get

<darobin> François

Anssi: we got some useful list of use cases from francois
... could look at prototyping
... there has been little progress under the current charter
... at the last F2F we quickly hacked together some quick design to replice the BONDI replica
... I'm trying to find out if that's on the critical path
... does the the group feel that the deliverable has decent use cases and there is demand from developers
... before investing time in a new draft
... coming up with good design and prototype will require some of my time that would be taken away from other deliverables work
... it's still largely unproven

<darobin> we're still switching to someone else

<darobin> rejoin!

<darobin> AnssiK: what is the kind of consensus around the priority for that API?

<darobin> ... I don't think that it has a proven track record

<darobin> ... not sure if the BONDI version materialised at all

<dom_> ScribeNick: dom_

<darobin> back

<darobin> we're redialing

<darobin> ... not clear that there's much prior art in this

<Zakim> fjh, you wanted to ask about how much to to be done

Frederick: how much work do you think this requires?

Anssi: the requirements from the use cases would require quite a number of features
... would probably start with something small
... I'm struggling to find what would be low-hanging fruit
... I welcome ideas around that
... we could simply conclude that we don't have currently enough interest
... whereas if it's clear that we have RoI, then I'm happy to do that
... I could do a small thing as a trigger for discussions

<fjh> +1 to low cost evaluation of where to begin

Anssi: we could probably take a file-picker approach for low-hanging — but not clear this brings any additional value over existing APIs

<darobin> +1 to code and small things

Dom: I would suggest doing some very rough, maybe a number of code examples of what the API would like
... and then bring it to the Web & TV IG to get feedback on usefulness/importance
... for instance, being able to search through your recorded collection of movies on your TV set-top box from your smartphone

<wonsuk> web and TV paper related with gallery API: http://www.w3.org/2010/11/web-and-tv/papers/webtv2_submission_6.pdf

Dom: could also look at position paper I noted to the mailing list which mentioned the need for a gallery API

Wonsuk: we need to make clear use cases for Gallery API
... we got use cases from Dom and Francois
... we also got one from Web & TV workshop
... we should enhance the use cases in the Gallery API doc
... might need also input to file systems API

<scribe> ACTION: Wonsuk to collect and summarize current use cases for Gallery API and includes a draft doc [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action12]

<trackbot> Created ACTION-368 - Collect and summarize current use cases for Gallery API and includes a draft doc [on WonSuk Lee - due 2011-03-23].

Wonsuk: there are lots of related specs: HTML Media Capture, Media Annotations, Media Ontology, FileSystems API
... this will require significant coordination

Dom: think writing code samples is best way to approach that complexity

Contacts API

-> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/att-0037/minutes-2011-03-09.html#item08 Discussion during last teleconf on Contacts API

Dom: only remaining thing is removing search filters, and then we can make a call for consensus for Last Call

Frederick: ok, so not much to discuss then

Calendar API

<fjh> http://dev.w3.org/2009/dap/calendar/

<darobin> navigator.service.calendar.EVENT_TYPE

Robin: could we go move forward with FPWD for Calendar?

<AnssiK> http://lists.w3.org/Archives/Public/public-contacts-coord/2011JanMar/0001.html

Contacts (Again)

Dom: we have a dependency on TZDate

Robin: doesn't seem to be a blocker for FPWD
... there has been an update to vCard 4
... don't think the last changes have an effect on Contacts, but could check
... I think Richard looked
... vCard4 is a superset of vCard3

Anssi: vCard2 and 3 were not explicit about the timezone format
... I sent a message to the list with a report on the differences

<AnssiK> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0087.html

Anssi: Olsson database is the recommended way, but many implementations only use utcOffset

Dom: This matches what's currently in the API

Calendar (again)

Robin: would be good to go to FPWD

Frederick: +1

Robin: would need maybe a quick review to remove most important bugs

<Zakim> fjh, you wanted to ask about publishing updated WD of calendar

Dom: should do a call for consensus

<fjh> +1

Dom: would like to make sure that the issue re TZDate is clearly documented in the draft, to avoid worrying people
... likewise for the recurrence model limitations

Robin: will send CfC then

Dom: I'll add the note on the issues in the draft

<dom> ScribeNick: dom

Roadmap

<fjh> http://www.w3.org/2009/dap/

-> http://www.w3.org/2009/dap/#roadmap DAP Roadmap

Frederick: we will not be meeting on Friday since we have already gone through the agenda and people have started to depart early
... regarding our roadmap, the rechartering doesn't prevent us from continuing our existing work, right?

dom: right

Frederick: let's look at our roadmap then
... we've determined a path for contacts
... likewise for Calendar, we've just sent a CfC for FPWD

Robin: if contacts goes to last call, we can hope to go to LC with Calendar soon (maybe June?)

Frederick: what about HTML Media Capture?

Robin: we're planning to publish an updated draft with a new attribute
... and depending on feedback, we might be able to go to LC soon

<AnssiK> Any feedback from Google? "As defined by the HTML Media Capture specification, the Browser allows web applications to access audio, image and video capture capabilities of the device." http://developer.android.com/sdk/android-3.0.html

<fjh> contacts - we have remaining edit from Rich, then CfC to go to Last Call in April

<fjh> calendar - CfC in place for publishing FPWD

<fjh> in April

PROPOSED RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done

<fjh> HTML Media Capture, outstanding edit from Dom then publish updated WD

Robin: you'll need to add an API for the new attribute based on WebIDL
... might use white-space separated tokens

RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done

<fjh> Media Capture API - looking for feedback on interest in it

close ACTION-351

<trackbot> ACTION-351 Draft HTML Media Capture with role attribute closed

<AnssiK> Microsoft's feedback

<scribe> ACTION: Robin to talk with Microsoft re Capture API future [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action13]

<trackbot> Created ACTION-369 - Talk with Microsoft re Capture API future [on Robin Berjon - due 2011-03-23].

Frederick: I think we're wondering about keeping it at all, vs upgrading it with stream support

Robin: I would qualify it as "future under discussion", decision expected sometimes in April

Frederick: Messaging will be updated with the new approach

Dom: and if no negative feedback, we can hope to go to last call in June
... re sysinfo, lots of work to take into account the new split
... I guess the plans for last call are probably less clear

Robin: some might be relatively straightforward

Dom: indeed, maybe Network could go quickly to LC

<fjh> Messaging - also updated WD in April

Frederick: Permissions API will get a FPWD

Dom: open question on merging the permissions API with the permissions strings

Robin: I'd rather keep them separate but don't mind strongly

Anssi: we could probably go fast unless we need coordination with Web Notif

Dom: don't think we need to coordinate

Frederick: so we can plan for a FPWD in April

Anssi: first step will be to put draft into ReSpec format
... and then bring in my changes
... I can do start and then pass it to Lazlo for review

Frederick: [bashing ReSpec]

<fjh> s/bashing/expressing admiration for/

Anssi: regarding merging with features ids or not
... I think they're independent

<fjh> we should ReSpec for our drafts to pick up common formatting, bibliography etc

Dom: thinking about it, I think they need to be kept independent since features ids are also useful for widgets feature
... we should publish an updated draft referring to the API once we go with FPWD

Anssi: wondering where the feature strings should go
... ideally, I think they should come with the API spec themselves
... but that's probably a minor issue
... I'm thinking the feature string could be a serialization of the entry of the APIs e.g. navigator.geolocation

Dom: I don't think that would work for all cases, e;g. when no direct entry point but from DOM element
... so I think arbitraty strings are probably our best option

Anssi: true

Frederick: for Gallery?

Dom: plan is to come up with code samples, formalized use cases

Robin: not ready to publish as is

Dom: re Device Interface?

<fjh> will wait with Gallery until clarity on requirements and draft

Robin: can have a draft next month

Dom: but do we still actually need it?

Robin: Contacts API doesn't use it anymore

Dom: now that we mention it, Contacts doesn't do HTML5 Event loop correctly, does?

Robin: doesn't look like it

ACTION-271?

<trackbot> ACTION-271 -- Robin Berjon to figure out the event loop stuff for sysinfo -- due 2010-09-22 -- OPEN

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

ISSUE: Contacts API needs to integrate HTML Event Loop

<trackbot> Created ISSUE-110 - Contacts API needs to integrate HTML Event Loop ; please complete additional details at http://www.w3.org/2009/dap/track/issues/110/edit .

Dom: so that's a showstopper for moving to LC

Robin: I hope the work in Web Apps for this for file API can serve as inspiration
... I'm not entirely sure if that's entirely needed

ACTION-271 due 2011-03-23

<trackbot> ACTION-271 Figure out the event loop stuff for contacts due date now 2011-03-23

Dom: moving back to Device Interface, should we drop it then?

<fjh> Not going further with Device interface

Robin: if nobody using it, sure

<fjh> Application Launcher, http://dev.w3.org/2009/dap/app-launcher/

Dom: re Application Launcher, we've talked about using Web Intents
... but we don't have a plan for it

Robin: I don't think anybody has volunteered for that

Dom: we could make a call for editors

<darobin> ACTION: Robin to talk to Mozilla/Paul about Web Intents [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action14]

<trackbot> Created ACTION-370 - Talk to Mozilla/Paul about Web Intents [on Robin Berjon - due 2011-03-23].

Kangchan: the proposed approach of Web Intent is quite different from the current API
... I've started discussing with Bryan and Paul to reconcile the views on this

Dom: what about Web Introducer? Should it be added to the roadmap
... ?

<darobin> ACTION: Robin to talk to Claes about how to make Web Introducer happen in the WG [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action15]

<trackbot> Created ACTION-371 - Talk to Claes about how to make Web Introducer happen in the WG [on Robin Berjon - due 2011-03-23].

Robin: I think that would make sense
... we need to see if they're still interested in doing work on this as part of the group

ACTION-353?

<trackbot> ACTION-353 -- Dominique Hazaël-Massieux to check with Claes re Web introducer contributors and bringing it to DAP -- due 2011-03-22 -- OPEN

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

<fjh> it would be best to have active participation of those who created the draft in the DAP WG

close ACTION-353

<trackbot> ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP closed

ACTION-353: overtaken by ACTION-371

<trackbot> ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP notes added

Dom: next is Tasks
... it has been suggested it could be a simple addition to the Calendar API

Frederick: would qualify as unscheduled work for now

Dom: will add relationship to Calendar in roadmap too
... probably worth taking up with the Calendar editors to see if they want to fold it in

<fjh> might make sense to include tasks with calendar since tasks are time based events

How does tasks relate to Process management?

Dom: different topic, but we could consider process management as part of new charter

Robin: please send use cases and potential input to the list if you want to include it in consideration for new charter

Dom: nothing has been done on User Interaction
... we want to do vibration, beep and menus per our new charter
... Opera has said they have proposals in this space

Robin: for menus and vibration

<scribe> ACTION: Dom to talk with Opera on contributions for User Interactions deliverable [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action16]

<trackbot> Created ACTION-372 - Talk with Opera on contributions for User Interactions deliverable [on Dominique Hazaël-Massieux - due 2011-03-23].

Dom: Communication Log to be dropped
... likewise for Policy Framework

Frederick: we should keep ref to them in a history section somewhere

Dom: re APIs requirements, can hope to update for May

ACTION-281 due 2011-05-10

<trackbot> ACTION-281 Take a stab at updating the API Requirements documents due date now 2011-05-10

Dom: policy-reqs is probably done

Robin: should we end of life it?

Frederick: we might want to update it at some point

Dom: we could publish it as a note to mark it as done

<scribe> ACTION: Frederick to prepare policy-reqs as WG Note [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action17]

<trackbot> Created ACTION-373 - Prepare policy-reqs as WG Note [on Frederick Hirsch - due 2011-03-23].

Dom: what about privacy-reqs?

Frederick: it's an important doc

Dom: how are we intending to make progress on privacy-reqs
... ?

Frederick: workshops are a way to get input

Dom: I think we are less likely to make progress if we don't have a plan, but don't mind keeping it as is

Frederick: re Rulesets
... I think we should publish it as FPWD, despite its issues

Robin: reading the document, it's not clear what it is supposed to do

Dom: it doesn't tell how the rulesets are bound to data

<fjh> so your concern is the lack of clarify of how this would integrate in the API architecture

Robin: I still think there is no point in using Rulesets in the same way as Geopriv
... attaching information to an API is something that no-one wants to do

Dom: we had interesting discussions in a previous F2F about using rulesets only in some cases (e.g. with Web site with which you have no pre-exisitng relationship)
... there were quite a few ideas

<fjh> possible need to capture ideas in rulesets proposal for this and other ideas

Dom: but they need to be captured as text and discussed if we want to make progress

<scribe> ACTION: Frederick to complete Privacy Rulesets with binding considerations [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action18]

<trackbot> Created ACTION-374 - Complete Privacy Rulesets with binding considerations [on Frederick Hirsch - due 2011-03-23].

Dom: last one is API Design Patterns, can be removed

<scribe> ACTION: Dom to add API Checklist to home page [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action19]

<trackbot> Created ACTION-375 - Add API Checklist to home page [on Dominique Hazaël-Massieux - due 2011-03-23].

Dom: I think documenting our experience could be useful
... could help make the Web a better place
... I wouldnt' phrase it as "you should do this or that", but rather here what've faced and learned

<fjh> Thank you to our hosts and Kangchan

<fjh> Next F2F is in July in France, please complete questionnaire http://www.w3.org/2002/09/wbs/43696/juljun-f2f/

<fjh> for information on upcoming meetings and minutes see http://www.w3.org/2009/dap/minutes

Adjourn

Summary of Action Items

[NEW] ACTION: Anssi to provide first editors draft of a Battery status API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action02]
[NEW] ACTION: Bryan to provide use cases for device characteristics access [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action05]
[NEW] ACTION: Bryan to split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action03]
[NEW] ACTION: Dom to add API Checklist to home page [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action19]
[NEW] ACTION: Dom to restart with HTML WG on getting new attribute for HTML Media Capture [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action10]
[NEW] ACTION: Dom to see with Maria on how to proceed for updated messaging api draft [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action07]
[NEW] ACTION: Dom to talk with Opera on contributions for User Interactions deliverable [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action16]
[NEW] ACTION: Dom to update HTML Media Capture with new attribute [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action11]
[NEW] ACTION: Frederick to complete Privacy Rulesets with binding considerations [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action18]
[NEW] ACTION: Frederick to help raise the COW [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action09]
[NEW] ACTION: Frederick to prepare policy-reqs as WG Note [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action17]
[NEW] ACTION: Kangchan to provide use cases for sysinfo-like features [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action06]
[NEW] ACTION: Robin to get the COW started [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action08]
[NEW] ACTION: Robin to talk to Claes about how to make Web Introducer happen in the WG [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action15]
[NEW] ACTION: Robin to talk to Mozilla/Paul about Web Intents [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action14]
[NEW] ACTION: Robin to talk with Microsoft re Capture API future [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action13]
[NEW] ACTION: Suresh to provide first draft of Network Connection API [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action01]
[NEW] ACTION: Suresh to see at possibilities of APIs for access to device characteristics [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action04]
[NEW] ACTION: Wonsuk to collect and summarize current use cases for Gallery API and includes a draft doc [recorded in http://www.w3.org/2011/03/16-dap-minutes.html#action12]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $