- From: <Frederick.Hirsch@nokia.com>
- Date: Thu, 7 Feb 2013 14:57:46 +0000
- To: <public-device-apis@w3.org>
- CC: <Frederick.Hirsch@nokia.com>, <wonsuk11.lee@samsung.com>, <w3c@adambarth.com>, <dsr@w3.org>, <dom@w3.org>
[Sending to DAP mail list and chairs/team, as I'm not a member of SysApps] There is some overlap of the Device APIs WG (DAP) [1] and System Applications WG (SysApps) [2] deliverables which may require some coordination. Specifically, both DAP and SysApps have the following work items (using SysApps terminology) 1. Contacts SysApps Phase 1 deliverable, (editors draft http://sysapps.github.com/sysapps/proposals/Contacts/Contacts.html ) DAP : "Contacts API", http://www.w3.org/TR/2011/WD-contacts-api-20110616/ and "Pick Contacts Intent" , http://www.w3.org/TR/2012/WD-contacts-api-20120712/ 2. Network Interface API SysApps Phase 2 deliverable, may build on DAP deliverable DAP: Network Information API, under current development, https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html ----- DAP also has items that have been 'shelved' [3] which means DAP currently has old drafts that are no longer being progressed, but which might be picked up again 3. Messaging API SysApps Phase 1 deliverable (editors draft http://sysapps.github.com/sysapps/proposals/Messaging/Messaging.html ) DAP - currently "shelved" , http://dev.w3.org/2009/dap/messaging/ 4. Calendar SysApps Phase 2 deliverable DAP - currently "shelved", http://dev.w3.org/2009/dap/calendar/ 5. Device Capabilities SysApps Phase 2 deliverable DAP "System Information API" - shelved, http://dev.w3.org/2009/dap/system-info/ ----- In addition, in passing I note the following might have some relation to Web Crypto 6. Secure Elements API SysApps Phase 2 deliverable. No corresponding DAP deliverable, but how does this relate to the Web Crypto WG [4] deliverables? ----- Conclusion I think it would be helpful to share use cases and requirements and also consider the implications of overlap work items. In particular, regarding Contacts, we may want to (a) make sure that the data formats and meaning are consistent (for interoperability) (b) ask whether similar APIs across two groups should share a common API style and practices [5] and maybe even details apart from optional parameters or intentionally be different (whether it is better to enable commonality or make clear distinctions) Thoughts? I hope this is helpful. regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group [1] http://www.w3.org/2009/dap/ [2] http://www.w3.org/2012/sysapps/ [3] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0026.html [4] http://www.w3.org/2012/webcrypto/ [5] API checklist, http://www.w3.org/2009/dap/wiki/ApiCheckList Web API Design Cookbook, http://darobin.github.com/api-design-cookbook/ For tracker, complete ACTION-612
Received on Thursday, 7 February 2013 14:58:28 UTC