w3c automotive and web platform business group n.
Skip this Video
Loading SlideShow in 5 Seconds..
W3C Automotive and Web Platform Business Group PowerPoint Presentation
Download Presentation
W3C Automotive and Web Platform Business Group

Loading in 2 Seconds...

play fullscreen
1 / 12

W3C Automotive and Web Platform Business Group - PowerPoint PPT Presentation

  • Uploaded on

W3C Automotive and Web Platform Business Group. April 22, 2013. 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):

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'W3C Automotive and Web Platform Business Group' - megan

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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


  • Andy Gryc - QNX
  • Adam Abramski - Intel


  • Name
  • Position
  • Company
public vs private
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


  • 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
vehicle data web api specs
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
scope of the spec
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?
roles and responsibilities
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)
  • 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.”

top level organization of a spec
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.
top level organization of a s pec content detailed
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; // …};

next steps
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