W3c automotive and web platform business group
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

W3C Automotive and Web Platform Business Group PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

W3C Automotive and Web Platform Business Group

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


W3c automotive and web platform business group

W3C Automotive and Web Platform Business Group

April 22, 2013


Practicals

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


Introductions

Introductions

Chairs

  • Andy Gryc - QNX

  • Adam Abramski - Intel

    Introductions

  • 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 - [email protected] Private - [email protected]


  • Charter

    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


    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)


    Process

    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.”


    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


  • Login