RE: [admin] Relationship of DAP and SysApps deliverables

Hi. Frederick.

Thanks for great summary!

 

 

> -----Original Message-----

> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]

> Sent: Thursday, February 07, 2013 11:58 PM

> To: public-device-apis@w3.org

> Cc: Frederick.Hirsch@nokia.com; wonsuk11.lee@samsung.com; 

> w3c@adambarth.com; dsr@w3.org; dom@w3.org

> Subject: [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/

 

For Contacts, in my understanding, DAP is trying to develop the contacts
spec based on Web Intents (instead of Contact APIs) because of privacy and
security issue. So I would like to propose to separate the R&R of DAP WG and
Sys Apps WG as Sys Apps WG has a role for contacts APIs and DAP WG has a
role for contact spec based on Web Intents(or Web Activity).

 

 

> 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

 

Sys Apps WG charter has below description for Network Interface API. This
description already considered Network Interface API in DAP WG. So Sys Apps
WG probably should change the name of the spec for removing confusion, but
content of the spec would not be overlapped with Network Interface API of
DAP WG.

 

An API to manipulate network interfaces (mobile, WiFi, etc.), such as
listing available networks, current strength, etc., as well as configuring
and enabling them. It may build atop the simpler network information API
that Device APIs is working on. Potential uses include offloading
connections from mobile networks to WiFi, enabling high priority mobile data
connections and control of other network features.

 

> -----

> 

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

 

I am not sure but I think this might has security and privacy issues. For
example, crazy web app could send an SMS/MMS/email to somewhere else without
user permission. So I think Sys Apps WG might be better location for making
this spec. What do you think?

 

 

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

 

Web Cryptography API from Web Crypto WG is to define a javascript API for
performing basic cryptographic operations in web applications, such as
hashing, signature generation and verification, and encryption and
decryption.

But according to Gemalto SecureElement API proposal, this spec is to define
a javascript API for allowing the communication between web application and
a smart card or other secure element by using the Application Protocol Data
Units (APDUs) So these would have a relationship but goal and use cases are
different.

 

> -----

> Conclusion

> 

> I think it would be helpful to share use cases and requirements and 

> also consider the implications of overlap work items.

 

I agreed for Calendar, Device Capabilities. 

 

> 

> In particular, regarding Contacts, we may want to

> 

> (a) make sure that the data formats and meaning are consistent (for

> interoperability)

 

I agreed.

 

> (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)

 

Generally I agreed. But there are many descriptions in [5]. So it would be
required to review by Sys Apps WG.

 

 

Best regards,

Wonsuk.

 

> 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