RE: [Inquiry on W3C Vehicle Specification] Hello, This is Lux Lee working for Obigo in South Korea

Thank you Urata-san!
/pw

From: Shinjiro Urata [mailto:shinjiro.urata@access-company.com]
Sent: Wednesday, August 31, 2016 5:35 AM
To: Lux Lee
Cc: Peter Winzell; public-automotive@w3.org; jongseon.park@lge.com
Subject: Re: [Inquiry on W3C Vehicle Specification] Hello, This is Lux Lee working for Obigo in South Korea

Hi Lux-san, Peter-san,

Excuse me to jump in.

Thus, may I ask you to answer at least to the #1 Inquiry and #3 Inquiry?

#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'] ] );
In my understanding, this usage (specify position in Zone constructor's argument)
 is not defined in spec.

navigator.vehicle.door.get( zn1 ).then( function(doorData){
This usage( specify array of Zones in get()'s argument) is not defined, too.

   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'].

I think doorFrontLeft is instance of 'Door Interface'. So, it just has attributes such as, status, lock, zone, timestamp.
If witdth, height, length, doorCount is Vehicle's width, height, ...., then thet are attribute of 'SizeConfiguration interface'.


(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.
   */

});

This is also not defined in the spec.

In the spec, some detail of Zone usage is not defined
 and left as implementation dependent.
So I think you can implement these usage in your code as
 implementation dependent behavior.


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

Since the activity to develop older spec forward is already discontinued,
I think these extension will be cosidered as your own extended specification.

Kind regards,
Shinjiro Urata


2016-08-29 23:02 GMT+09:00 Lux Lee <Lux.Lee@obigo.com<mailto:Lux.Lee@obigo.com>>:
Dear Peter Winzell,

First, I deeply appreciate your prompt response to my email.
Also, thank you a lot for the hot W3C news. ☺ The renewal concept of Zone seems to be much more clear than before!!!

However, I am a little concerning about the project schedule.
I mean I should implement the depreciated specification first, and re-work later to implement the new concept of W3C Vehicle Specification.
Thus, may I ask you to answer at least to the #1 Inquiry and #3 Inquiry?

Also, if there is anything to help W3C Automotive Group, please let me know.
These days, I am working on other service domain except Vehicle such as POI, Map, and so on for automotive..

Thank you!!

Sincerely yours,

Lux.

From: Peter Winzell [mailto:Peter.Winzell@melcogot.com<mailto:Peter.Winzell@melcogot.com>]
Sent: Monday, August 29, 2016 7:16 PM
To: Lux Lee; public-automotive@w3.org<mailto:public-automotive@w3.org>
Cc: jongseon.park@lge.com<mailto:jongseon.park@lge.com>
Subject: RE: [Inquiry on W3C Vehicle Specification] Hello, This is Lux Lee working for Obigo in South Korea

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<mailto:public-automotive@w3.org>
Cc: jongseon.park@lge.com<mailto: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<tel:%2B82%2031%208033%203087>
Mobile     +82 10 3122 7030<tel:%2B82%2010%203122%207030>
Fax         +82 31 8033 3011<tel:%2B82%2031%208033%203011>
Rep.        +82 31 8033 3000<tel:%2B82%2031%208033%203000>
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.


.