# Device APIs and Policy Working Group Teleconference ## 16 Mar 2011 [Agenda][3] See also: [IRC log][4] ## 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 * [Topics][5] 1. [Admin][6] 2. [sysinfo and sensors][7] 3. [messaging][8] 4. [feature permissions][9] 5. [success criteria][10] 6. [security][11] 7. [testing][12] 8. [HTML media capture][13] 9. [Contacts API][14] 10. [Gallery API][15] 11. [Contacts API][16] 12. [Calendar API][17] 13. [Contacts (Again)][18] 14. [Calendar (again)][19] 15. [Roadmap][20] 16. [Adjourn][21] * [Summary of Action Items][22] * * * Date: 16 March 2011 Sorry for not attending meeting in this morning. I will be there afternoon. trackbot-ng, start telecon Meeting: Device APIs and Policy Working Group Teleconference Date: 16 March 2011 ScribeNick: bryan ScribeNick: bryan_sullivan ### Admin yes Can we swap the morning and afternoon items in today's agenda? Suresh, which items specifically would you like to switch? agenda bashing... ### sysinfo and sensors bryan: is this discussion in context of breaking sysinfo into pieces? 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 [SysInfo editors draft][23] Did we talk about a vocabulary approach, yesterday? [http://dev.w3.org/2009/dap/system-info/#system-properties][24] 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? 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 For static properties, we could define a very simple getPropXX () type API and for dynamic APIs decide how we want to proceed 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 cf. [http://en.wikipedia.org/wiki/Procfs][25] 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? [Rich's proposal for simple Network API][26] +1 for the Network dom: the next step is to find an editor for the network info API I plan to take an iteration on the network part Battery would be another, which IMHO should not have privacy issues [navigator.connection in Android][27] +1 to Rich's proposal dom: for the network API, richt made a proposal for the network API 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? **ACTION:** Suresh to provide first draft of Network Connection API [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action01][28]] 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 Battery status **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][29]] 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 ACTION-358: Web Performance WG was interested on battery status — probably need coordination ACTION-358 Provide first editors draft of a Battery status API notes added CPU is something device vendors like to keep it to themselves 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 [https://developer.mozilla.org/en/DOM/window.navigator.oscpu][30] dom: for the sensors, we have the question of a generic sensor API. Anssi sent something about what is available in android [https://developer.mozilla.org/en/DOM/window.navigator.platform][31] 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 **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][32]] Created ACTION-359 - Split out a generic sensors API (based on ambientlight/proximity/etc) from sysinfo [on Bryan Sullivan - due 2011-03-23]. navigator.platform and navigator.oscpu expose CPU-related information already today, works in Moz, Chrome, Saf at least 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) 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 **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][33]] Created ACTION-360 - See at possibilities of APIs for access to device characteristics [on Suresh Chitturi - due 2011-03-23]. 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 I heard Bryan or Suresh say something about screen related props, for existing ones, see: [http://www.quirksmode.org/dom/w3c_cssom.html][34] CSS OM exposes much information that is useful for developers, such as the dimensions of the viewport **ACTION:** Bryan to provide use cases for device characteristics access [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action05][35]] Created ACTION-361 - Provide use cases for device characteristics access [on Bryan Sullivan - due 2011-03-23]. 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 [Quota API discussion in WebApps][36] dom: suggest not to work on this given overlap with the work in webapps e.g. with filesystem 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. **ACTION:** Kangchan to provide use cases for sysinfo-like features [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action06][37]] Created ACTION-362 - Provide use cases for sysinfo-like features [on Kangchan Lee - due 2011-03-23]. ### messaging Suresh, you wanted to clarify the change in direction for Messaging [Dom's Messaging proposal][38] suresh: missed last week's discussion, if the group has agreed to simplify this, what is it based upon? 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: the latest proposal I sent for messaging is feature-equivalent to the draft we have currently published as working draft Super simplification would not allow us to extend in the future if we were to add folder management, search, etc. 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. 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 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 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 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 relying on libaries is not the same as having a standard API implemented in the browser.... dom: there are good reasons on both sides, let's put the two proposals on the table PROPOSED RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors) +1 perhaps as you suggest we should have a call for implementations RESOLUTION: publish new messaging API as WD and ask for feedback (esp. from developers and implementors) **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][39]] Created ACTION-363 - See with Maria on how to proceed for updated messaging api draft [on Dominique Hazaël-Massieux - due 2011-03-23]. just to summarize, we would present both the proposals and ask for feedback right> indeed, suresh thanks! ??P2 is DAPWG i will be here until noon session ### feature permissions [http://lists.w3.org/Archives/Public/public-device- apis/2011Mar/0012.html][40] anssik: the feature permissions spec is being produced by web notiifications group [http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermis sions.html][41] anssik: the deliverable is proposed to be moved to DAP I reached John Gregg and touch based on the spec [http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html][42] anssik: I have done some investigation and as demo that implements this with a usable interface 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 [http://dev.w3.org/2009/dap/docs/feat-perms/feat- perms.html#changes][43] 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. +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 [http://dev.w3.org/2009/dap/features/][44] dom: if you can bring in the Feature Permissions spec and propose changes based upon the investigation, that would be a start 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 Contacts/Calendar? but we may need Rich.. I'm happy to help Laszlo with editing Feat Perms ### success criteria 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 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 replacing the current statement with "APIs that can be demonstrated without the need of a specialized policy framework will be released" is a good alternative to indicate that the APIs will be demonstrated using the web runtime only and not with the assumption of an underlying policy framewrok 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 "without the need of a specialised policy framework" doesn't really help — it needs to also be safe 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 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 "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? [Content Security Policy][45] 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 **ACTION:** Robin to get the COW started [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action08][46]] Created ACTION-364 - Get the COW started [on Robin Berjon - due 2011-03-23]. **ACTION:** Frederick to help raise the COW [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action09][47]] 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 ACTION-298? ACTION-298 -- Dominique Hazaël-Massieux to work with rich on test- enabling the contacts API -- due 2011-03-09 -- OPEN [http://www.w3.org/2009/dap/track/actions/298][48] darobin: we need to test contacts soon close ACTION-348 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 DAP wiki for testing , including framework -> [http://www.w3.org/2009/dap/wiki/Testing][49] dom: one struggle will be defining a test environment e.g. due to dependency upon underlying data, which may require loading of fake data Dom is planning on testing related to contacts, so is Rich, plan to make call for contributions later I presented the QUnit-based approach to unit testing at the last f2f [http://www.w3.org/2009/dap/wiki/Testing#Notes_on_testing_framework_u sed_by_Phonegap][50] fjh: what about HTML media capture? the group decided to align with the WebApps WG harness instead dom: we are stuck ### HTML media capture 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 I believe jgraham of Opera is the original author of the WebApps harness contributed to W3C but I'm not 100% sure, Opera participants probably know the best **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][51]] 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 **ACTION:** Dom to update HTML Media Capture with new attribute [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action11][52]] Created ACTION-367 - Update HTML Media Capture with new attribute [on Dominique Hazaël-Massieux - due 2011-03-23]. ACTION-366: todo after ACTION-367 ACTION-366 Restart with HTML WG on getting new attribute for HTML Media Capture notes added plan is to update HTML Media capture, then publish new WD, get feedback, then consider last call [http://www.w3.org/TR/test-methodology/][53] bryan: what are the steps in getting ready for tests? darobin: there is a methodology linked from [http://www.w3.org/2009/dap/wiki/Testing][49] 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... [Web Tracking and User Privacy Workshop, April 28-29][54] [we're breaking until 2pm local time] AnssiK, we'll be using 26631 as a conf code; I'm not sure why the regular one doesn't work ScribeNick: dom ### Contacts API -> [http://dev.w3.org/2009/dap/contacts/][55] Contacts API Editors draft Frederick: actually, let's start with Gallery ### Gallery API ACTION-314? ACTION-314 -- Anssi Kostiainen to react on media gallery use cases -- due 2010-12-15 -- OPEN [http://www.w3.org/2009/dap/track/actions/314][56] [http://dev.w3.org/2009/dap/gallery/][57] Anssi: should look at use cases before deciding to work on it ... also need to check how much priority this should get 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 we're still switching to someone else rejoin! AnssiK: what is the kind of consensus around the priority for that API? ... I don't think that it has a proven track record ... not sure if the BONDI version materialised at all ScribeNick: dom_ back we're redialing ... not clear that there's much prior art in this 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 +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 +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 web and TV paper related with gallery API: [http://www.w3.org/2010/11 /web-and-tv/papers/webtv2_submission_6.pdf][58] 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 **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][59]] 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][60] 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 [http://dev.w3.org/2009/dap/calendar/][61] navigator.service.calendar.EVENT_TYPE Robin: could we go move forward with FPWD for Calendar? [http://lists.w3.org/Archives/Public/public-contacts- coord/2011JanMar/0001.html][62] ### 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 [http://lists.w3.org/Archives/Public/public-device- apis/2011Jan/0087.html][63] 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 fjh, you wanted to ask about publishing updated WD of calendar Dom: should do a call for consensus +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 ScribeNick: dom ### Roadmap [http://www.w3.org/2009/dap/][64] -> [http://www.w3.org/2009/dap/#roadmap][65] 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 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][66] contacts - we have remaining edit from Rich, then CfC to go to Last Call in April calendar - CfC in place for publishing FPWD in April PROPOSED RESOLUTION: we will publish a new updated HTML Media Capture once new attribute is done 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** Media Capture API - looking for feedback on interest in it close ACTION-351 ACTION-351 Draft HTML Media Capture with role attribute closed [Microsoft's feedback][67] **ACTION:** Robin to talk with Microsoft re Capture API future [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action13][68]] 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 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] s/bashing/expressing admiration for/ Anssi: regarding merging with features ids or not ... I think they're independent 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? 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? ACTION-271 -- Robin Berjon to figure out the event loop stuff for sysinfo -- due 2010-09-22 -- OPEN [http://www.w3.org/2009/dap/track/actions/271][69] ISSUE: Contacts API needs to integrate HTML Event Loop 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][70] . 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 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? Not going further with Device interface Robin: if nobody using it, sure Application Launcher, [http://dev.w3.org/2009/dap/app-launcher/][71] 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 **ACTION:** Robin to talk to Mozilla/Paul about Web Intents [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action14][72]] 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 ... ? **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][73]] 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? ACTION-353 -- Dominique Hazaël-Massieux to check with Claes re Web introducer contributors and bringing it to DAP -- due 2011-03-22 -- OPEN [http://www.w3.org/2009/dap/track/actions/353][74] it would be best to have active participation of those who created the draft in the DAP WG close ACTION-353 ACTION-353 Check with Claes re Web introducer contributors and bringing it to DAP closed ACTION-353: overtaken by ACTION-371 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 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 **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][75]] 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 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 **ACTION:** Frederick to prepare policy-reqs as WG Note [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action17][76]] 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 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 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 **ACTION:** Frederick to complete Privacy Rulesets with binding considerations [recorded in [http://www.w3.org/2011/03/16-dap- minutes.html#action18][77]] 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 **ACTION:** Dom to add API Checklist to home page [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action19][78]] 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 Thank you to our hosts and Kangchan Next F2F is in July in France, please complete questionnaire [http://www.w3.org/2002/09/wbs/43696/juljun-f2f/][79] for information on upcoming meetings and minutes see [http://www.w3.org/2009/dap/minutes][80] ### 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][29]] **[NEW]** **ACTION:** Bryan to provide use cases for device characteristics access [recorded in [http://www.w3.org/2011/03/16-dap- minutes.html#action05][35]] **[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][32]] **[NEW]** **ACTION:** Dom to add API Checklist to home page [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action19][78]] **[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][51]] **[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][39]] **[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][75]] **[NEW]** **ACTION:** Dom to update HTML Media Capture with new attribute [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action11][52]] **[NEW]** **ACTION:** Frederick to complete Privacy Rulesets with binding considerations [recorded in [http://www.w3.org/2011/03/16-dap- minutes.html#action18][77]] **[NEW]** **ACTION:** Frederick to help raise the COW [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action09][47]] **[NEW]** **ACTION:** Frederick to prepare policy-reqs as WG Note [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action17][76]] **[NEW]** **ACTION:** Kangchan to provide use cases for sysinfo-like features [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action06][37]] **[NEW]** **ACTION:** Robin to get the COW started [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action08][46]] **[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][73]] **[NEW]** **ACTION:** Robin to talk to Mozilla/Paul about Web Intents [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action14][72]] **[NEW]** **ACTION:** Robin to talk with Microsoft re Capture API future [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action13][68]] **[NEW]** **ACTION:** Suresh to provide first draft of Network Connection API [recorded in [http://www.w3.org/2011/03/16-dap-minutes.html#action01][28]] **[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][33]] **[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][59]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][81] version 1.135 ([CVS log][82]) $Date: 2009-03-02 03:52:20 $ [1]: http://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: http://www.w3.org/2009/dap/wiki/F2F_Agenda_15,_16,_18_March_2011,_Seoul [4]: http://www.w3.org/2011/03/16-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #item09 [15]: #item10 [16]: #item11 [17]: #item12 [18]: #item13 [19]: #item14 [20]: #item15 [21]: #item16 [22]: #ActionSummary [23]: http://dev.w3.org/2009/dap/system-info/ [24]: http://dev.w3.org/2009/dap/system-info/#system-properties [25]: http://en.wikipedia.org/wiki/Procfs [26]: http://lists.w3.org/Archives/Public/public-device- apis/2010Oct/0076.html [27]: http://lists.w3.org/Archives/Public/public-device- apis/2010Jul/0058.html [28]: http://www.w3.org/2011/03/16-dap-minutes.html#action01 [29]: http://www.w3.org/2011/03/16-dap-minutes.html#action02 [30]: https://developer.mozilla.org/en/DOM/window.navigator.oscpu [31]: https://developer.mozilla.org/en/DOM/window.navigator.platform [32]: http://www.w3.org/2011/03/16-dap-minutes.html#action03 [33]: http://www.w3.org/2011/03/16-dap-minutes.html#action04 [34]: http://www.quirksmode.org/dom/w3c_cssom.html [35]: http://www.w3.org/2011/03/16-dap-minutes.html#action05 [36]: http://lists.w3.org/Archives/Public/public- webapps/2011JanMar/0346.html [37]: http://www.w3.org/2011/03/16-dap-minutes.html#action06 [38]: http://lists.w3.org/Archives/Public/public-device- apis/2011Mar/0036.html [39]: http://www.w3.org/2011/03/16-dap-minutes.html#action07 [40]: http://lists.w3.org/Archives/Public/public-device- apis/2011Mar/0012.html [41]: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html [42]: http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html [43]: http://dev.w3.org/2009/dap/docs/feat-perms/feat-perms.html#changes [44]: http://dev.w3.org/2009/dap/features/ [45]: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp- unofficial-draft-20110303.html [46]: http://www.w3.org/2011/03/16-dap-minutes.html#action08 [47]: http://www.w3.org/2011/03/16-dap-minutes.html#action09 [48]: http://www.w3.org/2009/dap/track/actions/298 [49]: http://www.w3.org/2009/dap/wiki/Testing [50]: http://www.w3.org/2009/dap/wiki/Testing#Notes_on_testing_framework_us ed_by_Phonegap [51]: http://www.w3.org/2011/03/16-dap-minutes.html#action10 [52]: http://www.w3.org/2011/03/16-dap-minutes.html#action11 [53]: http://www.w3.org/TR/test-methodology/ [54]: http://www.w3.org/2011/track-privacy/ [55]: http://dev.w3.org/2009/dap/contacts/ [56]: http://www.w3.org/2009/dap/track/actions/314 [57]: http://dev.w3.org/2009/dap/gallery/ [58]: http://www.w3.org/2010/11/web-and-tv/papers/webtv2_submission_6.pdf [59]: http://www.w3.org/2011/03/16-dap-minutes.html#action12 [60]: http://lists.w3.org/Archives/Public/public-device- apis/2011Mar/att-0037/minutes-2011-03-09.html#item08 [61]: http://dev.w3.org/2009/dap/calendar/ [62]: http://lists.w3.org/Archives/Public/public-contacts- coord/2011JanMar/0001.html [63]: http://lists.w3.org/Archives/Public/public-device- apis/2011Jan/0087.html [64]: http://www.w3.org/2009/dap/ [65]: http://www.w3.org/2009/dap/#roadmap [66]: http://developer.android.com/sdk/android-3.0.html [67]: http://lists.w3.org/Archives/Public/public-device- apis/2011Mar/0015.html [68]: http://www.w3.org/2011/03/16-dap-minutes.html#action13 [69]: http://www.w3.org/2009/dap/track/actions/271 [70]: http://www.w3.org/2009/dap/track/issues/110/edit [71]: http://dev.w3.org/2009/dap/app-launcher/ [72]: http://www.w3.org/2011/03/16-dap-minutes.html#action14 [73]: http://www.w3.org/2011/03/16-dap-minutes.html#action15 [74]: http://www.w3.org/2009/dap/track/actions/353 [75]: http://www.w3.org/2011/03/16-dap-minutes.html#action16 [76]: http://www.w3.org/2011/03/16-dap-minutes.html#action17 [77]: http://www.w3.org/2011/03/16-dap-minutes.html#action18 [78]: http://www.w3.org/2011/03/16-dap-minutes.html#action19 [79]: http://www.w3.org/2002/09/wbs/43696/juljun-f2f/ [80]: http://www.w3.org/2009/dap/minutes [81]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [82]: http://dev.w3.org/cvsweb/2002/scribe/