RE: Gen2 ideas

Hi Rudy,

Thanks for your response.

>> I would call the property "access" considering that the settings are "none", "write", "readwrite".
With the property name "access", the enum values of it should in my view then be ["none", "read", "readwrite"].
With the (inverse) property name "(access)restriction", the enum values of it should in my view then be ["none", "write", "readwrite"].
Maybe it is easier to think of it in terms of what access rights the client has, instead of what access restrictions the client have.

>> 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)?
I agree with you that my solution on default settings for this is not so elegant. It is probably preferable to limit the introduction of new properties, and instead of having a separate property for default settings of this, use the "restricted"/"access" together with some rules that clearly defines its default logic. I think that your reasoning below on this points to a better solution that eliminates this second new property. Some more work on it, and it will be perfect:).
Overlays is a good candidate on how to superimpose this onto a tree. I believe Daniel is working on one solution to this also.

>> Actuator: write-only
In my reasoning above regarding the enum values for this new property, I have assumed that actuators are read-write.
I think my assumption aligns with how the "type" property is used in "VSS 2.0".

Regarding my array proposal, please see my response to Daniels comments on it.
BR
Ulf





Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A
Copenhagen, Denmark
volvocars.com

From: Rudolf Streif [mailto:rstreif@partner.jaguarlandrover.com]
Sent: den 14 maj 2019 22:15
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>; Björkengren, Ulf <ulf.bjorkengren@volvocars.com>; public-automotive <public-automotive@w3.org>
Subject: Re: Gen2 ideas

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.
:rjs
________________________________
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?



Regards,



/Magnus F.
-------------------
System Architect Manager
Jaguar Land Rover

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

[Image removed by sender.]

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


BR

Ulf



Ulf Björkengren Ph. D.

Connectivity Strategist



M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A
Copenhagen, Denmark
volvocars.com<https://eur02.safelinks.protection.outlook.com/?url=volvocars.com&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C5a05124e45a147a290d608d6d8a8dfcd%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636934617158863216&sdata=nfKCtYNp88S24B34%2F097aNWAlm84FiUgOHe4mpeOgxI%3D&reserved=0>

Received on Wednesday, 15 May 2019 09:38:13 UTC