Re: Divorcing the data from the Access API

Thanks, Paul. I will remove "third party" as you suggested.

What about the issues surrounding "property" versus Property? Shall I make a change in my draft, or should Kevron change the spec?

	In an earlier email, I asked: 
	One observation I had is that "properties" described in the API Introduction would read better if it was capitalized. This helps distinguish the naming convention throughout the API. That is my recommendation.

	If you disagree, you should REMOVE the capitalization of "Properties" within the Abstract. If you agree, you should 			capitalize "properties" within the API specification doc.

Cindy


On May 1, 2014, at 11:28 AM, Paul Boyes wrote:

> Cindy,
> 
> Thanks.  I think this is a very good pass.   The only thing I would change is remove “third party” from the following sentence:  "The key purpose of this specification is to promote an API enabling third party application development in a consistent manner across all automotive manufacturers.”  (This was there before your edits).  To me the spec is about app development  consistency in general, whether it be third party or within an OEM.
> 
> Other than that, I would merge it in if no one else has issue with it.
> 
> Paul J. Boyes
> --------------------------------
> Mobile:   206-276-9675    
> Skype:  pauljboyes    
> 
> 
> 
> 
> On Apr 30, 2014, at 4:20 PM, Lucinda Lewis <cindy.lewis@me.com> wrote:
> 
>> The W3C Vehicle Information API defines an Open Web Platform standard for HTML5/JavaScript application developers enabling Web connectivity through in-vehicle infotainment systems and vehicle data access protocols. This API can also be leveraged by HTML5/JavaScript applications running on mobile devices that access the data resources of a connected passenger vehicle.
>> 
>> This vehicle data API specification does not dictate or describe the access protocol or transport method used for the data connection. Data may come from numerous sources including OBD-II, CAN, LIN, etc. Bluetooth, WiFi, or cloud connections are all possible.
>> 
>> The key purpose of this specification is to promote an API enabling third party application development in a consistent manner across all automotive manufacturers. It is recognized, however, that the mechanisms required for access or control of vehicle Properties may differ between automobile manufacturers, makes and models. Furthermore, different automobile manufacturers may expose different Properties that can be read or set by an application.
>> 
>> As a result of these constraints, this specification shall allow for automobile manufacturer-specific extensions or restrictions. Extensions are only permitted for interfaces that are not already described by this API, and must be implemented to conform within the format and guidelines existing in this specification. If a Property is restricted, the automobile manufacturer would omit the optional feature in their implementation (see the Availability Section).
>> 
>> The target platform supported by the specification is exclusively passenger vehicles. Use of this specification for non-passenger applications (transportation, heavy machinery, marine, airline infotainment, military, etc.) is not prohibited, but is not covered in the design or content of the API and therefore may be insufficient.
>> 
>> Initially, a typical use case of Vehicle Information might be the implementation of a 'Virtual Mechanic' application that provides vehicle status information such as tire pressure, engine oil level, washer fluid level, battery status, etc. Future use case innovations in transportation, safety, navigation, smart energy grid and consumer infotainment and customization are all possible through this specification.
>> 
>> Web developers building interoperable applications based upon this W3C Vehicle API standard, will help empower a common web platform across consumer devices and passenger vehicles consistent with the Web of Things.
>> 
>