W3C home > Mailing lists > Public > public-autowebplatform@w3.org > April 2014

Re: Divorcing the data from the Access API

From: <andy@cx3marketing.com>
Date: Wed, 30 Apr 2014 19:23:35 -0400
Cc: "Rees, Kevron" <kevron.m.rees@intel.com>, Paul Boyes <pb@opencar.com>, Tina Jeffrey <tjeffrey@qnx.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Message-Id: <DEB68B5D-D6D2-4C0C-85F3-C54F27A9562C@cx3marketing.com>
To: Lucinda Lewis <cindy.lewis@me.com>
Very nice Cindy—quite readable.

—Andy


___________________________________________
Andy Gryc | Co-founder
M: +1 613.618.8730 | E: andy@cx3marketing.com
W: www.cx3marketing.com

On Apr 30, 2014, at 7:20 PM, Lucinda Lewis <cindy.lewis@me.com> wrote:

> Below, is a revision of the Vehicle Data Abstract doc. My primary objective was to increase "readability" of the document. I call it the "Geek to the Street" Abstract rendition. 
> 
> 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.
> 
> I'm happy to help resolve any questions or changes needed in the document below:
> --------------
> 
> 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.
> 
> On Apr 30, 2014, at 3:57 PM, Lucinda Lewis wrote:
> 
>> The data doc abstract is fine. 
>> 
>> I am slightly revising the vehicle doc based off the following outline:
>> 	Description of the Specification
>> 	Goals of API
>> 	Methods of Connection
>> 	Discussion of Issues
>> 	Target Platform
>> 	Typical Use Case
>> 
>> I will paste the revision into this email and you can review. If you find the edits/comments enhance the Abstract, then Kevron can add to the document.
>> 
>> Cindy
>> 
>> On Apr 30, 2014, at 3:50 PM, Rees, Kevron wrote:
>> 
>>> Right.  The abstract I was referring to was for the data doc.
>>> 
>>> 
>>> On Wed, Apr 30, 2014 at 8:16 AM, Paul Boyes <pb@opencar.com> wrote:
>>> Keep in mind that we now have two abstracts one for main doc and one for data doc.
>>> 
>>> 
>>> Paul J. Boyes
>>> --------------------------------
>>> Mobile:   206-276-9675    
>>> Skype:  pauljboyes    
>>> 
>>> 
>>> 
>>> 
>>> On Apr 30, 2014, at 6:36 AM, Lucinda Lewis <cindy.lewis@me.com> wrote:
>>> 
>>>> Thanks Tina and Paul, for bringing me up to speed on the Abstract status. I will look at it today and post to this thread any suggestions/revisions.
>>>> 
>>>> Cindy
>>>> 
>>>> On Apr 30, 2014, at 7:29 AM, Tina Jeffrey wrote:
>>>> 
>>>>> 
>>>>> Cindy
>>>>> 
>>>>> I made some changes to the spec's intro about a month ago. If you think it needs to be beefed up further that's fine.
>>>>> 
>>>>> Best
>>>>> Tina
>>>>> 
>>>>> Sent from my BlackBerry 10 smartphone on the Rogers network.
>>>>> From: Paul Boyes
>>>>> Sent: Tuesday, April 29, 2014 11:11 PM
>>>>> To: Lucinda Lewis
>>>>> Cc: Rees, Kevron; public-autowebplatform@w3.org
>>>>> Subject: Re: Divorcing the data from the Access API
>>>>> 
>>>>> Are you referring to the W3C Vehicle API Creation Guidelines?
>>>>> 
>>>>> http://lists.w3.org/Archives/Public/public-autowebplatform/2014Feb/att-0023/W3C_Vehicle_API_Creation_Guidelines_v4.docx
>>>>> 
>>>>> Paul J. Boyes
>>>>> --------------------------------
>>>>> Mobile:   206-276-9675    
>>>>> Skype:  pauljboyes    
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Apr 29, 2014, at 5:03 PM, Lucinda Lewis <cindy.lewis@me.com> wrote:
>>>>> 
>>>>>> Hi there,
>>>>>> 
>>>>>> Didn't Tina mention there was more detail in another document? If you could point me at the earlier draft, I will revise it.
>>>>>> 
>>>>>> Thanks,
>>>>>> Cindy
>>>>>> 
>>>>>> 
>>>>>> On Apr 29, 2014, at 6:57 PM, Rees, Kevron wrote:
>>>>>> 
>>>>>>> On Tue, Apr 29, 2014 at 2:24 PM, Paul Boyes <pb@opencar.com> wrote:
>>>>>>>> Kevron,
>>>>>>>> 
>>>>>>>> The normative use cases should probably go with the vehicle_spec.html
>>>>>>>> 
>>>>>>> 
>>>>>>> Good catch.  Correction made.
>>>>>>> 
>>>>>>> 
>>>>>>>> Paul J. Boyes
>>>>>>>> --------------------------------
>>>>>>>> Mobile:   206-276-9675
>>>>>>>> Skype:  pauljboyes
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Apr 29, 2014, at 11:32 AM, Rees, Kevron <kevron.m.rees@intel.com> wrote:
>>>>>>>> 
>>>>>>>> I forgot to include live links to my proposed changes:
>>>>>>>> 
>>>>>>>> http://rawgit.com/tripzero/automotive-bg/master/vehicle_spec.html
>>>>>>>> http://rawgit.com/tripzero/automotive-bg/master/data_spec.html
>>>>>>>> 
>>>>>>>> On Tue, Apr 29, 2014 at 11:31 AM, Rees, Kevron <kevron.m.rees@intel.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> https://github.com/w3c/automotive-bg/pull/28
>>>>>>>> 
>>>>>>>> I've got the first merge that separates the data from the main access
>>>>>>>> APIs.  We discusses modularizing the specification in the last face to
>>>>>>>> face meeting in Santa Clara.
>>>>>>>> 
>>>>>>>> I probably don't have the abstract correct for the vehicle data
>>>>>>>> specification, so any help there would be appreciated.
>>>>>>>> 
>>>>>>>> Any other comments welcome.
>>>>>>>> 
>>>>>>>> Kevron
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
Received on Wednesday, 30 April 2014 23:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:52 UTC