- From: Peter Winzell <Peter.Winzell@melcogot.com>
- Date: Mon, 29 Aug 2016 10:15:50 +0000
- To: Lux Lee <Lux.Lee@obigo.com>, "public-automotive@w3.org" <public-automotive@w3.org>
- CC: "jongseon.park@lge.com" <jongseon.park@lge.com>
- Message-ID: <F151E948D19EFA4A8D984455EF32D51701A5DE54CC@melcosse04.meaegot.local>
Hi Lux Lee! One note regarding your questions: The specification is undergoing some radical changes. The concept of Zone is deprecated and will not be a part of the final specification. The current status and changes are not final however. The zone concept is basically being replaced with ¡°branches¡± attached to a tree data object: [Description: File:Vss-tree.png] body.mirror.left.heated body.mirror.left.folded body.mirror.right.heated body.mirror.right.folded body.door.front.left.open body.door.back.left.open The data spec will be based on the Genivi VSS data specification which you can find here: https://github.com/GENIVI/vehicle_signal_specification There are many arguments why we are doing this change, but the main overall argument is that the old spec was not able to meet the industry requirements on adaption and flexibility. Br Peter Winzell From: Lux Lee [mailto:Lux.Lee@obigo.com] Sent: Monday, August 29, 2016 7:23 AM To: public-automotive@w3.org Cc: jongseon.park@lge.com Subject: [Inquiry on W3C Vehicle Specification] Hello, This is Lux Lee working for Obigo in South Korea To Whom It May Concerns, Hello! This is Lux Lee working for Obigo in South Korea. I am emailing this since I have some inquiries regarding W3C Automotive Vehicle Specification. I¡¯ve taken below links for my reference. #Link1 (Vehicle Information Access API) https://www.w3.org/2014/automotive/vehicle_spec.html#idl-def-Availability #Link2 (Vehicle Data) https://www.w3.org/2014/automotive/data_spec..html<https://www.w3.org/2014/automotive/data_spec.html> #1 Inquiry Please, check below two(2) cases are correct or not. (CASE-01) : get() with a parameter of Zone var zn1 = new Zone( [ ['front','left'] , ['rear','left'] ] ); navigator.vehicle.door.get( zn1 ).then( function(doorData){ /* In the returned doorData, I believe there are two Door Instances. The first Door instance is for ['front','left']. The second Door instance is for ['rear','left']. Thus, I can use the doorData as below. (* Let's suppose that in index 0 of the doorData, there is the Door instance for ['front','left']. ) var doorFrontLeft = doorData[0]; var doorRearLeft = doorData[1]; doorFrontLeft.zones.value will return an array of ['front','left']. doorRearLeft.zones..value will return an array of ['rear','left']. Plus, The instance of doorFrontLeft has attributes: width, height, length, doorsCount, and totalDoors which are for ['front','left']. The instance of doorRearLeft has attributes: width, height, length, doorsCount, and totalDoors which are for ['rear','left']. */ }); (CASE-02) : get() with no parameter of Zone navigator.vehicle.door.get().then( function(doorData){ /* In the returned doorData, I believe there are four(4) Door Instances. The first Door instance is for ['front','left']. The second Door instance is for ['front','right']. The third Door instance is for ['rear','left']. The fourth Door instance is for ['rear','right']. This is because I have guessed that a Door instance is created with its own zones. For your reference more, if I try to create an instance of WiperStatus, the instance will be created with its own zones: [ ['front'] , ['rear'] ]. Of course, all the data regarding Zone for Door, WiperStatus, or other attributes will be coming from the system, not me. If a vehicle has its wiper at the front only, then the instance of WiperStatus will have only [ [¡®front¡¯] ] zone for its own zones. */ }); #2 Inquiry I also need to define API not about Vehicle but POI (Points of Interest). In this case, am I required to define the API for POI like W3C Vehicle API Style as below Example-01? Example-01) navigator.poi.poiList.get( ).then(cbSuccess,cbError); Can I not define it as below Example-02? Example-02) navigator.poi.getPoiList( ).then(cbSuccess,cbError); #3 Inquiry If W3C Vehicle API Style is mandatory, can I add more methods such as remove() or update() so that I can define APIs for POI as below Example-03? Example-03) navigator.poi.removePoiList( ).then(cbSuccess,cbError) OR navigator.poi.updatePoiList( ).then(cbSuccess,cbError) // which prevents me from defining as below Example-04.. Example-04) navigator.poi.set( { type : remove, value: [poiList] } ).then(cbSuccess,cbError) #4 Inquiry Not for Vehicle but for different service domain such POI, can I start from a different object as below Example-05 but not navigator? Example-05) poi.poiList.get( ). then(cbSuccess,cbError) #5 Inquiry Do you have any other specification like Vehicle in order for Navigation, Bluetooth, Radio, GPS, or so on? I deeply appreciate you for reading. If you are busy to answer to above five(5) inquires, at least please and please reply me regarding the first inquiry. Your prompt response will be highly appreciated!!! Thank you. Sincerely yours, Lux. Lux Lee (ÀÌ»ó¿ø) OBIGO Inc. 3rd Fl, 338 Pangyo-ro, Bundang-gu, Gyeonggi-do, 463-400, Rep. of Korea Direct +82 31 8033 3087 Mobile +82 10 3122 7030 Fax +82 31 8033 3011 Rep. +82 31 8033 3000 E-mail lux.lee@obigo.com<mailto:User%20E-mail@obigo.com> Notice¡Ü The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Obigo shall not be liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.
Attachments
- image/png attachment: image001.png
Received on Monday, 29 August 2016 10:16:29 UTC