Re: comments on basic framework draft

That is exactly what I meant Andy.  It would seem that our discussion (perhaps disagreements) has centered around zone.  I have not seen any major criticisms of the rest of the API (other than DOMFuture->Promise, which has been changed).   Zone should definitely be extensible, but it is intended to only apply to those data elements that are location specific within a vehicle, such as HVAC.   I suggest we move forward with adding the data elements while settling on an extensible zone mechanism.  I do not think it will apply to most elements.

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes




On Jan 21, 2014, at 2:45 PM, Andy Gryc <AGryc@qnx.com<mailto:AGryc@qnx.com>> wrote:

I think the discussion on extensions isn't intended to be regarding plug-ins, but rather allowing an OEM to provide additional capability through existing APIs, which is a different thing altogether.

As we are expecting extensions, I do ‎agree that some generalized rules and mechanism for how an OEM would extend should be thought through.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Abramski, Adam M
Sent: Tuesday, January 21, 2014 5:33 PM
To: Paul Boyes; jongseon.park@lge.com<mailto:jongseon.park@lge.com>
Cc: Rees, Kevron M; Andy Gryc; Gerken, Stephen; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Grant Courville; Tina Jeffrey
Subject: RE: comments on basic framework draft


I agree Paul.  Just to clarify something, when it comes to extensions and a mechanism for such let’s leave that to the WebKit and Blinks of the world.  They have well defined plug-in mechanisms so anyone could write a JS plug in to cover APIs that are not defined in our spec but I agree that our spec isn’t meant to cover all possibilities.  I would like to see us come to a point (soon) where we can all live with and accept what’s being specified without having paralysis and trying to boil down and solve every possibility.

So far I’m happy to see this healthy debate and conversation happening but let’s make a conscience effort to not go “over-board”.  I would like to see a public draft spec of all the vehicle signals BEFORE we have our F2F in just 2 months ☺

Just my two cents and by the way I’m not trying to squash this conversation although whenever I chime in that seems to happen, maybe it’s just me.

Sincerely,
Adam

From: Paul Boyes [mailto:pb@opencar.com]
Sent: Tuesday, January 21, 2014 9:00 AM
To: jongseon.park@lge.com<mailto:jongseon.park@lge.com>
Cc: Rees, Kevron M; Andy Gryc; Gerken, Stephen; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Grant Courville; Tina Jeffrey
Subject: Re: comments on basic framework draft

It seems to me that the issue that Stephen brings up is one of extensibility.  Clearly the standard will not cover all possibilities, but could be more useful if it provides and defines the mechanism for extension.    In my opinion, regarding zone, we should only specify the practical (not the exhaustive).  Hopefully we can achieve consensus on the practical (especially since vehicles will always be full of exceptions), and provide a mechanism for extension.

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes



On Jan 21, 2014, at 1:25 AM, 박종선(Justin Park) <jongseon.park@lge.com<mailto:jongseon.park@lge.com>> wrote:


I have no objection to using array.

Usually, zones have been defined as complete compound words as like
"FrontLeft", "RearRight".
It's much simpler although it has a limitation for extension.

If we use a combination of "Front" and "Left" in an array, we need to
consider something more.

1) Do we allow seatPosition.zone[0] = "Front" (without following 'left',
'center', 'right') ?
  In case of 'Setting', users may want the command to take an effect on
whole 'front' seats.

2) Do we allow seatPosition.zone[0] = "Left", seatPosition.zone[1] =
"Front" as an opposite sequence?
  If we don't restrict which element can be located in the array, the code
must be much complicated.
  So, we may need to make a rule as like that "Front", "Middle", "Rear"
must be the first element of the array.

3) We will not care about which combination is possible.
  It depends on the implementer, and if wrong or non-existing combination
is used,
  the system shall respond that 'It's not supported'. That's all. Right?

4) It's hard to imagine how to use X, Y, Z coordinates to zone with 'left',
'front' things.
   I think it would be more clear to separate x, y, z axis from zone for
the data types fit to those system.

Is there any missing things to be considered?


-----Original Message-----
From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
Sent: Tuesday, January 21, 2014 2:09 AM
To: Andy Gryc
Cc: Gerken, Stephen; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Grant Courville; Tina
Jeffrey
Subject: Re: comments on basic framework draft

Having zones represented as an array seems reasonable.  In my own use
cases, code would only have to modified slightly but ease-of-use is still
preserved.  For example, instead of checking the  bitfild if the attribute
is in "Front", you can use indexOf() with the same effect.

If Justin is okay with using an array, I'll make the change with the other
changes and push it for additional comment.

-Kevron



On Mon, Jan 20, 2014 at 8:12 AM, Andy Gryc <AGryc@qnx.com<mailto:AGryc@qnx.com>> wrote:

Thanks so much Stephen, I'm very glad that you helped fill out the
discussion we had on Tuesday.

I completely agree with your comments regarding bitfields and how they
may not work for the purpose of extendability-I mentioned the same
concern on the call. The concept of lists will be needed elsewhere
too, so I think it's important that they are supported. For example,
in the QNX piece that I added types & ranges too, the same need for
lists came up in describing door configurations. I'll have to leave it
up to Kevron, Justin and anyone else WebIDL-expert who wants to chime
in (Paul? Aldric?) on precisely how we would implement it.

I'm not sure what the right representation of zone would be, but thank
you so much for your use cases. They will greatly help us in figuring
out a proper representation.
--Andy

From: <Gerken>, Stephen <sgerken@jaguarlandrover.com<mailto:sgerken@jaguarlandrover.com>>
Date: Friday, 17 January, 2014 4:29 PM
To: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Subject: comments on basic framework draft
Resent-From: <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Resent-Date: Saturday, 18 January, 2014 5:17 PM

Hi all,

Below please find comments on the basic framework draft as found at
https://raw.github.com/tripzero/automotive-bg/master/vehicle_spec.html

as of 17th January 2014.

The general appearance of the document is consistent with expectations
for a W3C standard.  The document is well laid out and well organized.

The concept of "zone" as presented in the draft appears to be an
attempt to capture the concept that multiple sensors on a vehicle will
report data of the same data type, and that within a group of such
sensors reporting on a common data type, it may be useful to
distinguish individual sensors from one another on a basis of physical
location.  While the underlying concept is sound and worthwhile, the
particular implementation of "zone", as detailed in the draft, is
incomplete.


As drafted, "zone" is a solely planar distinction, with bitfielded
values for front/mid/rear, left/center/right.  For some vehicle
equipment, this division may be sufficient; many passenger car models
have four wheels, four seats, and four or five doors, which can be
adequately described as a wheel in the front right zone, a seat in the
rear left zone, or a door in the center rear zone (a hatchback).
However, even with these mundane examples, zones as currently
described do not adequately disambiguate equipment.  Some full-size
pickup trucks have dual rear wheels; for such models, "tire pressure
on wheel in right rear zone" describes two pressure sensors, one for
each of the dual right rear wheels.  We should not assume that no future
vehicle with dual wheels will be a passenger car.


Additionally, other equipment types will not disambiguate easily in a
planar zone concept.  For example, existing JLR models have up to 24
camera views.

Some cameras may be front-mounted but side-facing, while others may be
front-mounted but rear-facing.  There may be camera clusters in which
many cameras share a common mount point, for example in the rear right
quadrant, and for which the cameras are distinguished from one another
by view angle, view direction, spectrum of sensitivity, resolution, or
other factors not contained in a planar zone concept.  Generally,
equipment types for which a planar zone does not adequately locate a
single sensor include:

+ microphones, which may have multiple vertical placements within a
given planar zone;  + microphones, again, in that two mics in close
physical proximity may have different sensitivities;  + audio
speakers, which may have multiple vertical placements within a given
planar zone;  + audio speakers, again, for which woofers and tweeters
may share a planar zone;  + tire pressure, in the case of dual wheels
mentioned above;  + accelerometers, which in addition to physical
location, also have axes of sensitivity;  + cameras, which may have
differences of view angle, view direction, spectrum, and resolution as
discussed above;  + airbags, for which a right front zone may have
multiple airbags located in a body pillar and in the roof,
collectively forming a side curtain, and also an additional airbag
located in the front of the right front zone in the dash.

In light of the above examples of the diversity of sensors in modern
vehicles, and bearing in mind the creativity of current and future
automotive engineers, it would seem prudent to permits manufacturers
to specify bases for disambiguation of equipment which are not
restricted to a purely physical planar location, or even to a
predetermined set of bases of which we are currently aware.

As a technical point on the specific implementation of Zone, the
current implementation is as a bitfield.  This means Zone exists as a
single field within the interface, which is masked against predefined
constants in order to extract information from that field about which
specific zones are on or off.  Effectively, the Zone field carries
information as a fixed-length array of boolean values, where the array
length is either 16 (for a short, as currently defined) or 32 (if
altered to a long). With either 16 or 32 maximum possible masks, it is
entirely possible that the number of actual useful bases of
disambiguation would exceed the array length, leading to an awkward
overlaying situation; if this data type is for microphones, 0x80 means
speech spectrum, but if this data type is for speakers, 0x80 means
tweeters.  While subtyping the zone masks based on the data type is a
possible means of extending the zone space beyond 16 (or 32) values,
this approach is awkward to document and difficult to code correctly, and
should be avoided if possible.


It would be preferable for Zone to be an actual array, not a bitfield.
If Zone were an actual array, it could still be an array of ints, but
since masks wouldn't be necessary, the number of meaningful values of
those ints could be 2 ^^ 16 instead of 16.  So for example:
const short Front = 0x0001;
const short Middle = 0x0002;
const short Rear = 0x0003;
const short Left = 0x0004;
const short Center = 0x0005;
const short Right = 0x0006;
const short Xaxis = 0x0007;
const short Yaxis = 0x0008;
const short Zaxis = 0x0009;
...
const short MfgBase = 0x8000;
const short JLROuter = MfgBase + 0x0040; const short JLRInner =
MfgBase + 0x0041; ...
VehicleCommonDataType{ ... readonly attribute Zone[] zone; ... }...
such that a returned instance tpres of VehicleTirePressureDataType has
tpres.zone[0] == Rear, tpres.zone[1] == Left, tpres.zone[2] == JLRInner.

Also, as a minor copyediting detail, the word "information" in the
draft is variously misspelled as "inforomation" and "Infomration".

Generally however it's clear that a lot of effort and thought has gone
into bringing the document to it's current draft state, and there is
good material here which is worth building upon as the scope of the
document is fleshed out.

Regards,
Steve Gerken
-------------------
Linux Developer
MSX, as broker for Jaguar Land Rover

One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland,
Oregon,
97204
Email: sgerken@jaguarlandrover.com<mailto:sgerken@jaguarlandrover.com>