[admin] Relationship of DAP and SysApps deliverables

[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