Re: incorrect "unsigned short" in Vehicle Data doc

On Tue, Oct 7, 2014 at 4:58 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Hi,
>
> While glancing through
> https://rawgit.com/w3c/automotive-bg/master/data_spec.html I noticed the
> following properties are marked as "unsigned short" while they are
> described as taking negative values:
> * Mirror.mirrorPan
> * Mirror.mirrorTilt
> * SeatAdjustment.reclineSeatBack
>
> It is also a bit unexpected that some times, percentages are used
> relative to the per-vehicle maximum values (e.g.
> SeatAdjustment.seatCushionHeight), and other times, they're used as
> absolute values matching a pre-defined maximum value (e.g.
> SeatAdjustment.reclineSeatBack)
>
> Some of the percentage values are defined as "unsigned byte" (whereas
> most are defined as "unsigned short"): Sunroof.openness, Sunroof.tilt,
> SideWindow.openness.
>
> 9.3 says that RainSensor provides information about ambient light levels
> — I assume it should be rain intensity.
>
> The mapping between the various interfaces that inherit from
> VehicleCommonDataType and the objects that can be used in the
> VehicleSignalInterface.set method is not well-defined at the moment;
> clearly, the "zone" attribute is not expected to set both in these
> objects and as the second parameter of VehicleSignalInterface.set.
>
> It's not clear to me why the "zone" attribute of the various
> VehicleCommonDataType interfaces is not always read-only; that being
> said, given that these objects will mostly only be made available as
> parameters to the "subscribe" callback, it's not clear that these
> "readonly" annotations have any actual impact on the API; the objects
> would probably better represented by dictionaries rather than
> interfaces, or at an even broader level, the subscribe method would
> probably better be represented by an event listener.
>

The interface vs dictionary is probably more of a style issue than a
functional one.  The important point that we wanted to address was to
define the types so that developers know what to expect.

With regard to subscribe, this concern has been brought up multiple
times.  We did not feel it was possible to subscribe to a specific
zone using the typical event listener syntax (ie.
vehicle.addEventListener("Door", handlerCallback)).  Which zone are
you listening for?  all zones?  We could have overloaded the
traditional function to add a zone argument, however, that's
effectively what we have now only we call it "subscribe" and we don't
pass in string values for the data type we want:
vehicle.door.subscribe(zone, handlerCallback).

The point about zone consistency being readonly is valid.  I will fix that.

Thanks again,
Kevron

> Dom
>
>
>

Received on Wednesday, 8 October 2014 16:33:55 UTC