Charter for the Automotive and Web Platform Business Group (better formatting, no changes to charter)

Automotive and Web Platform Charter

Date: 2013-02-13


Goals


The goal of the Automotive and Web Platform Business Group (BG) is to
accelerate the adoption of Web technologies in the automotive industry.
In order to achieve this mission, the group will bring developers,
automotive manufacturers, automotive suppliers, browser vendors,
operators and other relevant members of the industry together to:


1. Create specifications, starting with the Vehicle Data API
Specification.

2. Create conformance tests to cover new specifications that get
defined.

3. Provide use cases and other reports to identify additional needed
standards work and to drive successful automotive web deployments.


Scope of Work


The group will produce the following types of deliverables:


Specifications

The group will develop a Specification for an API to expose vehicle
data and information from an automotive network bus(es) (e.g. MOST or
CAN) to a Web application.  The  API will expose information like the
vehicle brand, model, year, fuel type, transmission type, steering
wheel position, tire pressure, oil level, wiper position, lights,
doors, windows and seating settings as well as navigation, trip
computer data, climate control data, speed, rpms, acceleration, gears,
park sensors and other vehicle sensors.  How an implementation obtains
this data is not in the scope of the group.

The Contributor License Agreement
(CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section
does apply to Specifications.


Test suites


High-quality, comprehensive and automated test suites are important
interoperability drivers.  The group will endeavor to create test
suites for each specification it releases.  Test Code will be
contributed under a 3 clause BSD License.

The Contributor License Agreement
(CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section
does not apply to test suites.


Non-normative Reports


Since participants will reflect diverse interests within the automotive
ecosystem, the group plans to document a variety of (non-normative) use
cases and other reports. These may serve as input to other W3C (or non-
W3C) groups to indicate capabilities that need to be standardized.

In particular, the group will look at the technologies in the Open Web
Platform and will determine if they meet the special needs of use in
automobiles.  By identifying use cases not satisfied by current Open
Web Platform Specifications, this group will attempt to influence WGs
in W3C and elsewhere to deliver the capabilities in their
Specifications that the Web in autos need.

The group will also determine what future work this group should
undertake.

The Contributor License Agreement
(CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section
does not apply to these non-normative reports.


Deliverables


The group will ONLY produce Specifications listed here.  To add any
additional specifications, the Charter must be amended by the process
described below.  All deliverables for which the CLA patent section
applies must be designated as such here.


Non-Normative Reports - CLA patent section does not apply
The group will produce reports, as described in the scope section, on
the use of Open Web Platform technologies in the automotive space.


Specifications - CLA patent section applies
Vehicle Data API - APIs to report vehicle information as described in
the scope section of the Charter.


Test Suites - Contributions under BSD 3 clause license
Test suites will be created for each of the Specifications in the
previous section.


Dependencies or Liaisons

  *   For the reports produced, including use cases, it may be useful
to contact members of W3C WGs such as the SysApps WG, Web Apps WG, Web
Apps Security WG, CSS WG and many others.
  *   There are no external specs that must be created before the
Specification to be developed here can be completed.



Community and Business Group Process


Anything in this charter that conflicts with requirements of the
Community and Business Group Process is void.


Choosing a Chair


This group chooses their Chair(s) and can replace the Chair(s) at any
time using whatever means they prefer. However, if 5 participants - no
two from the same organization - call for an election, the group must
use the following process to replace any current Chair(s) with a new
Chair, consulting the Community Development Lead on election operations
(e.g., voting infrastructure and using RFC 2777).


Participants announce their candidacies. Participants have 14 days to
announce their candidacies, but this period ends as soon as all
participants have announced their intentions. If there is only one
candidate, that person becomes the Chair. If there are two or more
candidates, there is a vote. Otherwise, nothing changes.


Participants vote. Participants have 21 days to vote for a single
candidate, but this period ends as soon as all participants have voted.
The individual who receives the most votes - no two from the same
organization - is elected chair. In case of a tie, RFC2777 is used to
break the tie. An elected Chair may appoint co-Chairs.


Participants dissatisfied with the outcome of an election may ask the
Community Development Lead to intervene. The Community Development
Lead, after evaluating the election, may take any action including no
action.



Decision process



This group will seek to make decisions when there is consensus. When
the group discusses an issue on the mailing list and there is a call
from the group for assessing consensus, after due consideration of
different opinions, the Chair should record a decision and any
objections.


Participants may call for an online vote if they feel the Chair has not
accurately determined the consensus of the group or if the Chair
refuses to assess consensus. The call for a vote must specify the
duration of the vote which must be at least 7 days and should be no
more than 14 days. The Chair must start the vote within 7 days of the
request. The decision will be based on the majority of the ballots
cast.


It is the Chair's responsibility to ensure that the decision process is
fair, respects the consensus of the CG, and does not unreasonably favor
or discriminate against any group participant or their employer.



Transparency



The group will conduct all of its technical work on its public mailing
list.. Any decisions reached at any meeting are tentative and must be
confirmed on the mail list.



Amendments to this Charter



The group can decide to work on a proposed amended charter, editing the
text using the Decision Process described above. The decision on
whether to adopt the amended charter is made by conducting a 30-day
vote on the proposed new charter. The new charter, if approved, takes
effect on either the proposed date in the charter itself, or 7 days
after the result of the election is announced, whichever is later. A
new charter must receive 2/3 of the votes cast in the approval vote to
pass.


The group may make simple corrections to the charter such as
deliverable dates by the simpler group decision process rather than
this charter amendment process. The group will use the amendment
process for any substantive changes to the goals, scope, deliverables,
decision process or rules for amending the charter.



Adam M Abramski
Product Planner
Intel Software & Services Group
503-264-8269 (o)
503-550-7910 (m)
adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>