Re: Vehicle Information API Draft Now Published

A few comments about the doc:

About VehicleInterface...  While I agree that certain values are
unlikely to change in a typical setup, I'm not convinced they will
never change in any setup.  Take for example a use case where I take
my vehicle-aware smartphone from one vehicle to the other.  If these
values do not indicate to the app they have changed, the user will
have to close the app and restart it.  Do we want to support this type
of use-case?  I defer to the wisdom of the group.  It's also possible
to mark the subscribe, unsubscribe and set as nullable types
indicating that they may not always be available depending on the
attribute's characteristics.

I don't have a huge problem with being more specific in the types of
access interfaces we use.  Let me know what the group decides and I'll
make the change if any.

Your Availability and identification recommendations makes sense to me.

-Kevron

PS.  If possible, I'd prefer these types of discussions to happen
directly in email rather than via an attachment.  It's easier for me
to inline comments in emails.



On Thu, May 22, 2014 at 9:11 PM, Vadim Draluk <vadim.draluk@gm.com> wrote:
> Team,
>
>
>
> Attached please see some material for discussion in today’s meeting
>
>
>
> Cheers
>
>
>
> Vadim
>
>
>
> From: Vadim Draluk
> Sent: Monday, May 19, 2014 6:15 PM
> To: 'Paul Boyes'; public-autowebplatform@w3.org;
> internal-autowebplatform@w3.org
> Subject: RE: Vehicle Information API Draft Now Published
>
>
>
> Team,
>
>
>
> Below please see some questions and thoughts on new documents, mostly to be
> considered as something to discuss at our F2F.
>
>
>
> 1.      The Vehicle Information API paper
>
>
>
> Security. I’ve had some extensive written and verbal discussions with Dave
> Ragget, chair of the Apps WG that is covering security. My impression is
> that the group is right now focusing on defining a common security model
> specifically for Web apps, not necessarily embedded ones (where they believe
> there’s little chance to reach a consensus between existing platforms). This
> is the opposite of at least GM priorities, which are right now firmly with
> variations of the embedded variety (including ones running in the IVI unit
> and, albeit with lower priority, ones deployed in mobile devices).
>
>
>
> Hope we have time to talk about it during our F2F. We will probably have to
> settle for some wording that delegates permissions to two layers above, the
> JS app FW layer (Tizen, QNX, whatever else) and the OS layer (after all,
> permissions have to be generated into, say, Android manifest, and these are
> likely to be based on ones defined for underlying native functions).
>
>
>
> Availability. I think the current proposal is quite good as it stands now.
> I’d like to clarify couple of things, such as:
>
> -        Do we need a return code indicating that user consent dialog has to
> be displayed? Not saying it’s really required, as it can be made part of the
> implementation as APIs are asynchronous – still would like to talk it
> through
>
> -        Do all the “negative” codes in Availability correspond to
> permission_denied in VehicleInterfaceError?
>
>
>
> 2.      The Vehicle Data doc
>
>
>
> UnitsOfMeasure. The interface does not fully reflect the proposal I’ve
> written up and adjusted according to quite a few comments I have received.
> It is missing quite a few units that are in the proposal. Elsewhere in the
> document I only see SI-based values returned. So looks like this interface
> is not completely incorporated into the doc in its full and most
> comprehensive form
>
>
>
> DriverIdentification. IMO this one has to be substantially generalized. Key
> fob is only one method of identification, and there are already other
> methods deployed, announced or implemented: face recognition, Bluetooth,
> eventually fingerprint and whatever else. A good overall approach would be
> to separate ID type (one of the above) and the actual ID whose semantics is
> determined by the type.
>
>
>
> TransmissionConfiguration. Should “dsg” not be a separate value if “cvt” is
> one?
>
>
>
> TripMeter. Is there an event that resets the trip meter? If so, it would be
> meaningful to have an API that supports callback upon this event, so that
> apps can do their own adjustment.
>
>
>
> TransmissionMode. Should we account for modes like “Sport”, “Winter” and
> such?
>
>
>
> CruiseControlStatus. Should apps be able to subscribe to “+” and “-“ events?
>
>
>
> DeadReckoning. Looks too low-level to be exposed to apps, usually calculated
> into location info, often in a separate ECU, not available to IVI at all
>
>
>
> Odometer. Many vehicles have support for at least two parallel trip counters
> – should we account for that?
>
>
>
> Tire. How does one get readings for a specific tire? Not saying it’s not
> there, just can’t find it. Or is it Zone-based? If so, should be made
> explicit
>
>
>
> DriveMode. This one looks very confusing. Not clear whether it pertains to
> transmission or suspension, and looks like it has components of both
> (“comfort” looks like a suspension setting, “sport” can apply to either one
> whereas “eco” looks very much like transmission related. Not sure what
> “manual” has to do with any of it).
>
>
>
> VehicleSound. Wondering what can one do with engineSoundEnhancementMode,
> especially given that it’s marked as OEM-specific from the get-go
>
>
>
>
>
> From: Paul Boyes [mailto:pb@opencar.com]
> Sent: Friday, April 25, 2014 9:33 AM
> To: public-autowebplatform@w3.org; internal-autowebplatform@w3.org
> Cc: Vadim Draluk
> Subject: Vehicle Information API Draft Now Published
>
>
>
> The Vehicle Information API draft is now published in the reports section
> here:
>
>
>
> http://www.w3.org/community/autowebplatform/
>
>
>
> Please review and send your questions and comments to the group.
>
>
>
> Thanks to everyone who has helped get the specification to this point.
>
>
> Paul J. Boyes
>
> --------------------------------
>
> Mobile:   206-276-9675
> Skype:  pauljboyes
>
>
>
>
>
>
>
>
>
> Nothing in this message is intended to constitute an electronic signature
> unless a specific statement to the contrary is included in this message.
>
> Confidentiality Note: This message is intended only for the person or entity
> to which it is addressed. It may contain confidential and/or privileged
> material. Any review, transmission, dissemination or other use, or taking of
> any action in reliance upon this message by persons or entities other than
> the intended recipient is prohibited and may be unlawful. If you received
> this message in error, please contact the sender and delete it from your
> computer.

Received on Friday, 23 May 2014 16:01:04 UTC