W3C Automotive and Web Platform Business Group

1. W3C Automotive and Web Platform Business Group April 22, 2013

2. Practicals Meeting Minutes • IRC - http://irc.w3.org with a web browsers and we can specify the channel name "#auto" on that portal page to join the channel • Need volunteers to take notes for each topic area (primary/secondary): • Intros (?/?) • Public v Private (?/?) • Vehicle Data Web API Specs (?/?) • Scope of Spec (?/?) • Roles and Responsibilities/Process/Organization of a Spec (?/?) • Sample Specs (?/?) • Next Steps (?/?)

3. Introductions Chairs • Andy Gryc - QNX • Adam Abramski - Intel Introductions • Name • Position • Company

4. Public vs Private • Meeting agenda • Private • Public • Meeting minutes • Private • Public • Technical/Use Case conversations • Private • Public • Reports (including draft specs, test suites and draft use cases) • Private • Public • Discussion • Public - public-autowebplatform@w3.org Private - internal-autowebplatform@w3.org

5. Charter Goals • Create specs, starting with Vehicle Data • Create conformance tests to cover new specs • Provide use cases and other reports to identify add’l needed standards work & to drive successful automotive web deployments

6. Vehicle Data Web API Specs • QNX (30 min) • Tizen (30 min) • GENIVI/LGE (30 min) • Webinos – No presentation • Spec - http://dev.webinos.org/specifications/api/vehicle.html • Previous presentation from the W3C Automotive and Web Workshop Fall 2012 • Q&A - Discussion

7. Scope of the Spec • Spec does not include an implementation as there is proprietary issues in the protocol used by CAN and MOST data networks • What is the contentious vehicle data that should NOT be exposed in this first version of the draft spec? • What about reading vs writing vehicle data? • Discussion • Food for thought: • Which spec do we start from or do we start it from scratch or use a combination?

8. Roles and Responsibilities • All participants are encouraged to • Attend group’s formal meetings • Follow and participate in mailing list (+IRC) discussions – all technical discussions should happen on the group’s mailing list(s) • Review draft proposals, propose changes, fix spec bugs • Editor’s responsibilities • Edits the spec based on group consensus • Follows group’s technical discussion and integrate proposed changes • Makes sure someone in the group responds to comments submitted to the spec(s) • Practicalities • Each spec needs at least one active editor • The group agrees on the work mode such as “commit-then-review” vs. “review-then-commit” together with the editor(s)

9. Process • Describe the problem to solve, list use cases • List requirements for each use case • Share the use cases and requirements with the group, adjust based on feedback from the group • Study existing proposals, come up with new proposals, keep the proposal as simple as possible and defer “nice to haves” for later • Evaluate how well the proposals address the use cases and meet the requirements, choose/create/merge a proposal that the group thinks is the best fit • Write draft spec, tests, publish spec snapshot(s) Finally: “Some (but not all) Business Group Specifications are expected to serve as input to a Working Group.”

10. Top-level Organization of a Spec • Introduction – an overview of the technology • Conformance – how conformance is determined in the spec • E.g. “Everything in this specification is normative except for diagrams, examples, notes and sections marked non-normative. […] A user agent must also be a conforming implementation of DOM4.” • Terminology – definitions of terms used • E.g. “The term user credentials for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates.” • Content • Normative – requirements and definitions • Informative – everything else • References • Acknowledgements • Specs should follow the patterns and style established by other specs.

11. Top-level Organization of a Spec: Content (detailed) • Normative • Interface definition – Web APIs are defined using Web IDL, e.g.: • Requirements and definitions • “The XMLHttpRequest(options) constructor MUST run these steps” • Use RFC2119 terms must, should, may • Normative must statements should be testable • Informative • Everything that is not normative, e.g. use cases, code examples, diagrams • Must not use RFC2119 keywords, use “can” or “is” instead [Constructor(optional XMLHttpRequestOptions options)]interface XMLHttpRequest : XMLHttpRequestEventTarget { // event handler attribute EventHandleronreadystatechange; // …};

12. Next Steps • Looking beyond vehicle data, what’s to tackle next? • Recommend looking at all of the wonderful papers from the W3C Automotive and Web Workshop last fall: http://www.w3.org/2012/08/web-and-automotive/summary.html • UI Constraints (driver safety, distraction and adjusting the GUI) • Application Security and Safety (handling different input controls) • Navigation (see W3C Geolocation API) • Voice Recognition (see W3C Web Speech API) • Audio Policy Management (addressing policy and management of multiple sinks and sources) • Should we break into task forces to research various topics? • Example model we could follow: http://www.w3.org/2011/webtv/wiki/TF_handling_rule • Face to face in Tokyo • Wed May29th from 8/9am – 5pm • Co-located with the Automotive Linux Summit and LinuxCon • Register using email and link provided • More information on our wiki • Decisions should be discussed and made online and through the email distro list