W3C home > Mailing lists > Public > public-automotive@w3.org > May 2019

Re: Gen2 ideas

From: Rudolf Streif <rstreif@partner.jaguarlandrover.com>
Date: Tue, 14 May 2019 20:15:12 +0000
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>, Björkengren, Ulf <ulf.bjorkengren@volvocars.com>, public-automotive <public-automotive@w3.org>
Message-ID: <VI1PR04MB5328594DAFD8F7A27A2950A7E9080@VI1PR04MB5328.eurprd04.prod.outlook.com>
Hi Ulf,

Thanks for thinking about the next step.

I like your proposal. In regards to the slides:

  *   WS/http access restriction: I think that's a good idea. I second it.
  *   Access restriction tagging of resources: That is a good idea too.
     *   I would call the property "access" considering that the settings are "none", "write", "readwrite".
     *   I am missing "readonly" for the "access" property.
     *   For attributes which are readonly by default erroneous settings need to be addressed e.g. write or readwrite on an attribute is not allowed.
     *   Not sure why for branches the property would need to be called differently ("restricted-default"). Why wouldn't it just be "restricted" (or "access" according to my proposal)?
     *   To clarify:
        *   The branch setting would only apply if there is no explicit setting for a leaf.
        *   For branches inside of a branch aka a child-branch, the child-branch setting overrides the parent branch unless the child-branch does not specify it.
     *   Access restriction properties could be provided by OEMs in form of overlays.
     *   Probably need to call out the implicit access defaults for the different element types:
        *   Attribute: read-only
        *   Sensor: read-only
        *   Actuator: write-only
        *   Branch: none
        *   RBranch: none
  *   Array data type: Like Magnus, I am not entirely convinced of the "elements" property. It might be for backwards compatibility but if "value" now in general is expressed as an array that would not help much. An array is not a data type on its own as it holds multiple elements of a certain data type. Maybe "value" should be in general treated as an array of the data type but the server could unpack it automatically if there is only one element in the array e.g. instead of returning [5], it returns 5.

From: Magnus Feuer <mfeuer1@jaguarlandrover.com>
Sent: Tuesday, May 14, 2019 9:50 AM
To: Björkengren, Ulf; public-automotive
Subject: Re: Gen2 ideas

I like it.

Is there a reason for having a specified element count explicitly called out?

I can understand a max_elements count to put an upper limit on the array size, but the implementation will surely be able to figure out the number of elements that are currently stored in an array?


/Magnus F.

System Architect Manager
Jaguar Land Rover

Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871


Jaguar Land Rover North America, LLC
1450 NW 18th Ave, Portland, OR 97209
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a specific individual and purpose.  The information is private and privileged and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, please e-mail us immediately.  We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.

From: Björkengren, Ulf <ulf.bjorkengren@volvocars.com>
Sent: Tuesday, May 14, 2019 5:32:38 AM
To: public-automotive
Subject: Gen2 ideas



Ulf Björkengren Ph. D.

Connectivity Strategist

M +4553562142

94014 Lund R&D Tech Center
Frederikskaj 10A
Copenhagen, Denmark
Received on Tuesday, 14 May 2019 20:15:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:12 UTC