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

Re: The necessity of the Availability API

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Mon, 4 Aug 2014 10:14:03 -0700
Message-ID: <CAFW5wYbMWpe-ND+zTkXeuw-5MP8nUZ77s2LaLBa44=7yExdAuQ@mail.gmail.com>
To: Vadim Draluk <vadim@draluk.net>
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Inline

On Thu, Jul 31, 2014 at 10:03 AM, Vadim Draluk <vadim@draluk.net> wrote:
> Kevron,
>
> as you might have expected, I'm not thrilled with the proposal.
>
> Whatever the existing W3C patterns, I do firmly believe that automotive
> presents a set of business cases substantially different from that of
> desktop, mobile and alike. The main difference is in OEM-proprietary sensors
> which are considered to provide valuable (that is, monetizable) information
> to applications. So OEMs have much at stake here with ability to control
> and/or license access to this information. Having visibility into OAA
> dealings, I can assure you that this is not a position unique to GM.
>

Thank you for explaining to me this aspect.  However, I'm still
confused as to why an OEM wouldn't be able to use the existing W3C
pattern to control access.  Is the idea that the availability API
would indicate to developers that a particular property is supported,
but only through licensing?  If so, it seems more appropriate that
documentation provided by the OEM should indicate this.  I don't see
the value of knowing this at runtime unless there is some way for the
user to do something about it (in-app purchase-like functionality?).

> You are correct when stating that some developers may not care and may not
> use this API, but others will want to act differently, depending on whether
> a particular signal is not available because it is not supported on the
> vehicle, blocked for security reasons or restricted out of business
> considerations. For such developers the API is necessary, and for OEMs
> expressing this functionality is paramount.
>
> At the same time, I agree that availability changes is not something of
> critical importance or of much use, so this part of the API can be removed.
>
> Hope for your understanding of this OEM perspective
>
> Cheers
>
> Vadim
>
>
>
> ________________________________
> From: "Rees, Kevron" <kevron.m.rees@intel.com>
> To: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
> Sent: Thursday, July 31, 2014 9:46 AM
> Subject: The necessity of the Availability API
>
> I'm continuing this previously private conversation on the public list.
>
> The argument has been made that if there is to be an availability API,
> that it should be at the attribute level.  Further, it has been argued
> that it can only be at the attribute level.  It is not useful at the
> interface level.
>
> I agree with the argument.  However, I question the premise: that the
> availability API is necessary at all.
>
> To sum up my rationale, I'll make a couple arguments:
>
> 1 - The pattern is new to the W3C and overrides existing patterns
> 2 - availability adds unnecessary complexity to the API and developers
> might not use it
>
> 1 - The availability API is an alien pattern to the w3c.  Attributes
> on interfaces are typically marked with "?" (nullable mark) to imply
> availability.  Take the geolocation API as an example[1]:
>
> interface Coordinates {
> ...
> readonly attribute double? altitude;
> ...
> };
>
>
> "The altitude attribute denotes the height of the position, specified
> in meters above the [WGS84] ellipsoid. *If the implementation cannot
> provide altitude information, the value of this attribute must be
> null*." (emphasis mine)
>
> 2 - Given that we already make liberal usage of the nullable marker
> (?), with the availability API we have effectively multiple ways of
> discovering whether or not an attribute is provided.  Developers who
> are accustomed to w3c patterns will likely use the former method and
> ignore the availability API.  None of the applications we have in
> Tizen at the moment will use the availability API.  It's hard to say
> if application developers will use it or find it useful given the
> already established pattern.
>
> Possible objections:
>
> "The Availability has advantages over the w3c pattern: it helps
> developers understand why an attribute is unavailable."
>
> I don't think we have a well-established use-case that justifies this
> pattern.  Developers might only care if it's available or not and may
> not care why.  We need to establish a better use-case if we want to
>
> "It also notifies developers if that availability changes."
>
> It is true a system *could* change the availability of an attribute
> for numerous perceivable reasons.  This is true.  However, unless we
> have a concrete example of a system that does this today or will in
> the future, we are coding in assumptions that may never be realized.
>
>
> I propose eliminating the availability API altogether and using "?" to
> connotate availability as established by other w3c specifications.
>
> Comments welcome,
> Kevron
>
> [1] - http://dev.w3.org/geo/api/spec-source.html
>
>
>
Received on Monday, 4 August 2014 17:14:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:53 UTC