Feedback on Vehicle Web API style

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

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

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?

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

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;
};

-----------------------------------------------------------------

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, 26 December 2013 04:58:19 UTC