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

Re: Feedback on Vehicle Web API style

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Thu, 2 Jan 2014 11:02:51 -0800
Message-ID: <CAFW5wYaqMjuYyWOCOGPeyHin6AobopBubMvaxWJnsW=hFqx+aQ@mail.gmail.com>
To: Futomi Hatano <futomi.hatano@newphoria.co.jp>
Cc: public-autowebplatform@w3.org
Thanks Futomi.  Those are some excellent comments.  More inline:

On Wed, Dec 25, 2013 at 8:57 PM, Futomi Hatano
<futomi.hatano@newphoria.co.jp> wrote:
> Hi all,
> I'm Futomi Hatano, a web developer, CTO, Newphoria Corporation.
> I'm writing to this ML for the first time.
> I'm interested in Vehicle Web API. I just join this BG.
> I have some feedbacks and questions on Vehicle Web API style.
> https://github.com/tripzero/automotive-bg/blob/master/vehicle_spec.html
> -----------------------------------------------------------------
> * DOMFuture Interface
> -----------------------------------------------------------------
> I wonder if the DOMFuture interface is as same as the DOM Promise.
> http://www.w3.org/TR/dom/#promises
> If so, I think this section is needless in the spec,
> and the WebIDL for VehicleInterface Interface should be tweaked as below.
> ---
> [NoInterfaceObject]
> interface VehicleInterface {
>   Promise get (...);
>   Promise set (...);
>   ...
> }
> ---
> Some specs which adopt the DOM Promise are helpful.
> http://www.w3.org/TR/webmidi/#requestmidiaccess
> http://www.w3.org/TR/discovery-api/#requesting-networked-services

You are correct.  DOMFuture is the same as Promise.  I had to define
DOMFuture so respec wouldn't complain because DOMFuture is not an idl
type.  I'll try with Promise.  Thanks.

> -----------------------------------------------------------------
> * subscribe()/unsubscribe() methods in the VehicleInterface Interface
> -----------------------------------------------------------------
> I think the interface should adopt the DOM Event model,
> that is, addEventListener() and removeEventListener().
> http://www.w3.org/TR/dom/#events

addEventListener() has no concept of zone.

> The subscribe()/unsubscribe() approach is not able to handle multiple event types.
> Let's assume that we will define the battery status interface, for example.
> If we adopt the subscribe()/unsubscribe() approach,
> app developers can get only an event for a change of charge level.
> Some developers would want an event for a change of charging or not.
> Some developers would want an event for a change of estimated remaining running distance.
> When we accept these needs, how can we resolve?

I think this can be handled, but it depends on how the data types are
defined.  For example, if there is a type for BatteryChargeLevel the
subsribe would work like this:


But if it's a more complex object like BatteryType {  attribute short
chargeLevel; ...} then you would access it like this:

vehicle.battery.subscribe( function (battery) { console.log("battery
level: " + battery.chargeLevel); } );

> -----------------------------------------------------------------
> * The zone attribute in the VehicleCommonDataType Interface
> -----------------------------------------------------------------
> I don't think the zone attribute is appropriate as a "common" data type.
> It is relevant to only climate control, seat belt status, as far as I can imagine.
> The zone attribute is irrelevant to most of the interfaces which will be defined in the future.

There are many data types that do need zone.  Anything that has to do
with a passenger can have a zone (seat position, door locks, window
locks, etc).  Tires can also be arranged in a zone pattern.  Basically
anytime there is a data type that can occur in multiple physical
locations inside the vehicle would or could have a "zone" attribute.

> If the zone attribute will be kept in the VehicleCommonDataType,
> the description should be tweaked a little bit.
> Currently, the spec says:
> --
> zone of type Zone, readonly
>   must return zone for this data type or undefined if there is no zone associated with this data type
> --
> I think it should return null if there is no zone associated with this data type,
> because "undefined" implies the UA doesn't implement the property (attribute).
> -----------------------------------------------------------------
> * The time attribute in the VehicleCommonDataType Interface
> -----------------------------------------------------------------
> The attribute name "time" is ambiguous to me.
> It represents a time stamp when an event something had been fired, doesn't it?
> If so, I prefer "timeStamp".
> Besides, it should return DOMTimeStamp, not Date.
> The Date is not specified in W3C, it means just an ECMAScript object.
> Many other specs specified in W3C use "timeStamp" as a attribute name for time stamp,
> and it returns DOMTimeStamp.
> For example,
> http://www.w3.org/TR/dom/#event
> http://www.w3.org/TR/geolocation-API/#position_interface
> The DOMTimeStamp interface is specfied in DOM3 Core.
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp
> Though the DOMTimeStamp and the Date is identical in ECMAScript for practical purposes,
> W3C specs should be more versatile because W3C specs are not only for ECMAScript.
> interface VehicleCommonDataType {
>     ...
>     readonly    attribute DOMTimeStamp timeStamp;
> };

I agree.  I will change it to timeStamp of type DOMTimeStamp.  Thanks!

> -----------------------------------------------------------------
> Thanks for your time.
> Cheers,
> Futomi
> --
> Newphoria Corporation
> Chief Technology Officer
> Futomi Hatano
> --
> futomi.hatano@newphoria.co.jp
> http://www.newphoria.co.jp/
Received on Thursday, 2 January 2014 19:03:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:37 UTC