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>:

> Dear Peter Winzell,
>
>
>
> First, I deeply appreciate your prompt response to my email.
>
> Also, thank you a lot for the hot W3C news. J 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]
> *Sent:* Monday, August 29, 2016 7:16 PM
> *To:* Lux Lee; public-automotive@w3.org
> *Cc:* 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:
>
>
>
> [image: 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 <Lux.Lee@obigo.com>]
> *Sent:* Monday, August 29, 2016 7:23 AM
> *To:* public-automotive@w3..org <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 <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.
>

-- 
.