17 | 28 |

29 | 31 | 33 |

34 | 35 |

36 |

[DRAFT] Device APIs Working Group Charter

37 |

38 | The mission of the Device APIs Working Group is 39 | to create client-side APIs that enable the development of Web Applications that interact 40 | with device hardware, services and applications such as the camera, microphone, system 41 | sensors, address books, calendars, and messaging applications. 42 |

43 |

44 | Join the Device APIs Working Group. 45 |

46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 |

End date	@@@TBD: 2 years after ratification
Confidentiality	55 \| Proceedings are Public 57 \|
Chairs	Robin Berjon, Frederick Hirsch
Team Contact (FTE %: 20)	Dave Ragget, Dominique Hazaël-Massieux
Usual Meeting Schedule	Teleconferences: 1 per week (only as needed) Face-to-face: 2-3 per year (only as needed)

73 |

74 | 75 |

76 |

Goals

77 |

78 | The Device APIs Working Group aims at producing Web client-side APIs that 79 | facilitate deeper integration of Web applications into advanced capabilities 80 | of their host devices. 81 |

82 |

83 | These capabilities include access to a camera, microphone, address book, 84 | calendar, or system information such as network connection and battery level. 85 |

86 |

87 | Adding these advanced features to the Web environment empowers Web developers 88 | to create richer and more context-aware Web applications. 89 |

90 |

91 | Given the sensitive nature of the data and sensors to which these APIs grant access, 92 | the Working Group also aims at crafting APIs that are both secure and privacy-enabling 93 | by design, based on the current Web browser security model. This entails reusing 94 | existing browser-based security metaphors where they apply and looking into innovative 95 | security and privacy mechanisms where they don’t. 96 |

97 |

98 | 99 |

100 |

Scope

101 |

102 | The scope of this Working Group is this creation of API specifications for a device’s 103 | services that can be exposed to Web applications . Devices in this context include 104 | desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, 105 | TVs, cameras, and other connected devices. 106 |

107 |

108 | Priority will be given to developing simple and consensual APIs, leaving more complex 109 | features to future versions. 110 |

111 |

112 | This Working Group’s deliverables must address issues of accessibility, 113 | internationalization, mobility, 114 | security and privacy. 115 |

116 |

117 | Additionally, comprehensive test suites will be developed for each specification to ensure 118 | interoperability, and the group will create interoperability reports. The group will also 119 | maintain errata as required for the continued relevance and usefulness of the specifications 120 | it produces. 121 |

122 |

123 |

Success Criteria

124 |

125 | To advance to Proposed Recommendation, each specification is expected to have two independent 126 | implementations of all features defined in the specification, including implementation on a 127 | constrained device (e.g. mobile phone, TV, camera). 128 |

129 |

130 | APIs that cannot be demonstrated to be implementable securely within the default browser context 131 | will not be released. This does not preclude these APIs to support use cases of installable Web 132 | applications. 133 |

134 |

135 |

136 |

Out of Scope

137 |

138 | The definition of a policy framework that would allow using the defined APIs into a different 139 | security environment than the default browser context is out of the scope for this group. 140 |

141 |

142 |

143 | 144 |

145 |

Deliverables

146 |

147 |

Recommendation-Track Deliverables

148 |

149 | The working group will deliver the following specifications: 150 |

151 |

153 | Calendar API, an API to access a calendar service (e.g. to add an entry, to edit an entry, 154 | to delete an entry). 155 |
157 | Tasks API, an API to access a personal task management / organizer service (e.g. to add, 158 | edit, delete a task). 159 |
161 | Contacts API, an API to access a contacts or address book service (e.g. to add an entry, 162 | to edit an entry, to delete an entry). 163 |
165 | Capture API, an API to manage a device’s camera and microphone, e.g. to take a picture 166 | or record a sound. This work will be carried out in conjunction with the WebRTC WG. 167 |
169 | Messaging API, an API to create and send a message. The API may be agnostic to the underlying 170 | messaging service (e.g. e-mail, SMS, MMS). 171 |
An API to discover the current network characteristics.
An API to react to a device power status.
An API to retrieve data generically from sensors.
176 | An API that allows Web applications to register themselves as handlers/providers based on 177 | identifiers and an API that enables other Web applications to discover these handlers/providers 178 | and gain permission to interact with them. This is commonly known as Web Intents, though the 179 | final specification may carry a different name. This work will be carried out in conjunction 180 | with the Web Apps WG. 181 |
183 | Gallery API, an API to access the user's media gallery services (e.g. pictures, music play lists). 184 |
An API to manage vibration.
An API to manage application menus.
188 | An API to discover and communicate with devices and services on the same device, on the local 189 | network, or directly connected, e.g. by USB and Bluetooth (*). 190 |
An API to interact with services available over Bluetooth.
An API to process QR codes extracting them from stills or streams and returning their content.
194 | An API to install Web apps and to manage a client-side collection of Web apps that a user has installed. 195 |

197 |

198 | (*)Note: the Web and TV Interest Group and the Multimodal 199 | Interaction Working Group are also working on topics related to discovery APIs. The Device APIs 200 | Working Group will liaise with them on these topics. As the discussion evolves, the groups will 201 | investigate the opportunity of creating a separate Working Group dedicated to local device discovery. 202 |

203 |

204 | Where practical, the API specifications should use the Web IDL 205 | formalism. 206 |

207 |

208 | The Working Group may also enter into joint Task Forces with other groups (in particular with the 209 | Web Applications and WebRTC Working Groups), to collaborate on specifications that cross group boundaries. 210 |

211 |

212 |

213 |

Other Deliverables

214 |

215 | A comprehensive test suite for all features of a specification is necessary to ensure the 216 | specification’s robustness, consistency, and implementability, and to promote interoperability 217 | between User Agents. Therefore, each specification must have a companion test suite, which 218 | should be completed by the end of the Last Call phase, and must be completed, with an 219 | implementation report, before transition from Candidate Recommendation to Proposed Recommendation. 220 | Additional tests may be added to the test suite at any stage of the Recommendation track, and the 221 | maintenance of a implementation report is encouraged. 222 |

223 |

224 | The Working Group may also document in a Working Group Note the useful design patterns shared by 225 | the APIs it is developing. 226 |

227 |

228 | The Working Group is also planning to work on Best Practices for Privacy-sensitive Web applications, 229 | as well as documenting Privacy Use Cases and Requirements in Working Group Notes. 230 |

231 |

232 | Other non-normative documents may be created such as: 233 |

234 |

Primers
Requirements and use case document for specifications
Non-normative group notes

239 |

240 | Given sufficient resources, this Working Group should review other working groups’ deliverables that 241 | are identified as being relevant to the Working Group’s mission. 242 |

243 |

244 |

245 |

Milestones

246 |

247 | Note: The actual production of some of the deliverables may follow a different timeline. The group 248 | documents any schedule changes on the group home page. 249 |

250 |

2012Q3

253 |

254 | Working Group starts work under new charter and calls for proposals for new deliverables; the 255 | following documents are already on the Recommendation track: 256 |

257 |

Contacts API
HTML Media Capture
Messaging API
Calendar API
Battery Status API (CR)
Vibration API (CR)
Network Information API

266 |

267 | The following documents have editors draft: 268 |

269 |

Gallery API
Sensor API
Web Intents
getUserMedia()

275 |

2012Q4

Contacts API, HTML Media Capture, Network API enters Last Call

All the new deliverables have First Public Working Drafts

Battery and Vibration are Recommendations

2013Q1

Contacts, HTML Media Capture, Network APIs become Candidate Recommendations

2013Q4

All deliverables have reached at least Last Call status

2014Q2

All deliverables have reached Proposed Recommendation.

287 |

288 |

289 |

290 |

Dependencies

291 |

292 |

W3C Groups

293 |

294 | This Working Group’s specifications depend upon some specifications being developed by other 295 | Working Groups for example the Web Applications Working Group’s Web IDL specification. 296 |

297 |

298 | This Working Group is not aware of any dependencies other Working Groups’ specifications have on 299 | this Working Group’s specifications. 300 |

301 |

302 |

303 |

Liaisons

304 |

305 | This Working Group expects to maintain contacts with at least the following groups and Activities 306 | within W3C (in alphabetical order): 307 |

308 |

Geolocation Working Group: 311 | The Geolocation Working Group is chartered to develop the Geolocation API Specifications, of 312 | a similar kind to the ones developed by this group. 313 |
HTML Working Group: 316 | The HTML Working Group’s deliverables cover the security model implemented in Web Browsers; this 317 | security model imposes limitations on what an extended model for Web Applications can achieve. 318 |
Web Accessibility Initiative 320 | Protocols and Formats Working Group: 322 | To ensure this Working Group’s deliverables support accessibility requirements, particularly with 323 | regard to interoperability with assistive technologies, and inclusion in deliverables of guidance 324 | for implementing the group’s deliverables in ways that support accessibility requirements. 325 |
Web Applications Working Group: 328 | This group defines relevant specifications including Web IDL, 329 | and File API. A joint Task Force is in 330 | effect to produce Web Intents. 331 |
Web Notification Working Group: 334 | This group defines an API to use the device’s notification system to alert the user of applications-triggered 335 | events. 336 |
Multimodal Interaction Working Group: 339 | The MMI Working Group is defining an architecture that allows for several components to talk to each other, 340 | and has thus relevant experience in the field of devices and services discovery. 341 |
Web and TV Interest Group: 344 | This group provides use cases and requirements for using Web technologies on TV and thus important 345 | input on some of the APIs developed by the Device APIs Working Group. 346 |
The Web Real Time Communications Working Group: 349 | This group provides way to use the video stream from on-board media capture devices (camera, microphones) 350 | which needs to be compatible with what the Device APIs Working Group offers. A joint Task Force is in 351 | effect for the getUserMedia() specification. 352 |
The HTML Speech Incubator Group: 355 | This Incubator Group looks at analysing input from the user via on-board microphones and thus is a 356 | potential user of the APIs developed by the Device APIs group. 357 |

359 |

360 |

361 |

External Groups

362 |

363 | The following is a tentative list of external bodies the Working Group should collaborate with: 364 |

365 |

Ecma International Technical Committee 39 (TC39): 368 | This is the group responsible for EcmaScript standardization, and related EcmaScript features like E4X. As this 369 | Working Group is developing EcmaScript APIs, it should collaborate with TC39. 370 |
IETF: 373 | The IETF has created specifications that are related to some of the APIs in this WG’s scope. 374 |

376 |

377 |

378 | 379 |

380 |

Participation

381 |

382 | To be successful, this Working Group is expected to have 10 or more active participants for its duration, and 383 | to have the participation of the industry leaders in fields relevant to the specifications it produces. 384 |

385 |

386 | The Chair(s) and specification Editors are expected to contribute one to two days per week towards the Working 387 | Group. There is no minimum requirement for other participants. However, it should be noted that as defined by 388 | the Process Document, group 389 | participants need to attend most meetings, be familiar with documents and minutes of past meeting, and follow 390 | the relevant mailing lists to be considered in good standing; this is likely to require at least half a day a 391 | week. 392 |

393 |

394 | Based on the input from the group participants, the Chairs may also decide to create task forces that allow 395 | more focused discussions for topics that require specific expertise (e.g. PIM APIs). 396 |

397 |

398 | This Working Group will also allocate the necessary resources for building Test Suites for each specification. 399 |

400 |

401 | This Working Group welcomes participation from non-Members. The group encourages questions and comments on its 402 | public mailing list, public-device-apis@w3.org, which is 403 | publicly archived and for which there is 404 | no formal requirement for participation. The group also welcomes non-Members to contribute technical submissions 405 | for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under 406 | the W3C Patent Policy. 407 |

408 |

409 | 410 |

411 |

Communication

412 |

413 | Most of the technical work of the group is done through discussions on the 414 | public-device-apis@w3.org, 415 | the group’s public mailing list. Editors’ drafts and their editing history is available from a public W3C web 416 | site. The group’s action and issue tracking data is also public, as are the participants-approved 417 | minutes from all teleconferences and meetings. 418 |

419 |

420 | The Working Group’s Teleconferences focus on discussion of particular specifications, and are conducted on an 421 | as-needed basis. At least one short teleconference per week is expected. 422 |

423 |

424 | The group uses a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs 425 | and participants of the group, for Member-only discussions in special cases when a particular participant requests such 426 | a discussion. 427 |

428 |

429 | Information about the group (for example, details about deliverables, issues, actions, status, participants) is 430 | available from the Device APIs Working Group home page. 431 |

432 |

433 | 434 |

435 |

Decision Policy

436 |

437 | As explained in the Process Document (section 3.3), 438 | this group seeks to make decisions when there is consensus. When the Chair puts a question and observes 439 | dissent, after due consideration of different opinions, the Chair should record a decision (possibly 440 | after a formal vote) and any objections, and move on. 441 |

442 |

443 | This charter is written in accordance with Section 3.4, 444 | Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. 445 |

446 |

447 | 448 |

449 |

Patent Policy

450 |

451 | This Working Group operates under the W3C Patent 452 | Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue 453 | Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. 454 |

455 |

456 | For more information about disclosure obligations for this group, please see the 457 | W3C Patent Policy Implementation. 458 |

459 |

460 | 461 |

462 |

About this Charter

463 |

464 | This charter for this Working Group has been created according to 465 | section 6.2 of the 466 | Process Document. In the event of a conflict between this 467 | document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 468 |

469 |

470 | See also the previous charter for this group. 471 |

472 |

473 |

474 | Editor: Robin Berjon, co-Chair, based on the 475 | previous DAP Working Group’s charter 476 |

477 |

478 |

487 |