search

w3c / automotive

W3C Automotive Working Group Specifications
Other
146 stars 68 forks source link

Information about underlying VSS model incl. schema #424

Closed aw-muc closed 2 years ago

aw-muc commented 2 years ago

At the moment it is not directly possible to request the currently used VSS data model out of the VISS. As far as i understood there are currently two possible solutions to solve this issue:

  1. Perform a *-service discovery to get the complete meta-tree information of the data model, which is not really efficient at the VISS-server side, because the complete tree needs to build up during runtime.

  2. Query the VSS version as a first request out of the tree (if the vehicle supports that information) based on the following model VersionVSS.[Major|Minor|Patch|Label]. Based on that information the client, needs to have all possible VSS schema already available to choose the correct implementation or query the data model from a centralized service. But are these fields set as mandatory fields, because otherwise this work around would not work. Because if the car or the VISS implementation does not deliver the information the client would break or at least need to fall back to an unverified version.

Wouldn't it make sense to have the VSS schema information somewhere available within the VISS implementation so that a client can make a preflight request to determine the available version of the schema or can download the schema from a specified interface of the VISS?

erikbosch commented 2 years ago

Two aspects that came to my mind, with service discovery (https://www.w3.org/TR/viss2-core/#scope-list) you might not get the whole tree but only items you are "allowed to see", right? I guess this in some situations is an advantage of alternative 1, the application can adapt to what it has access to. (But then maybe you want to consider if you have read/write-access as well)

For alternative 2 I think we might need to consider the evolving VSS layering concept (see https://github.com/GENIVI/vehicle_signal_specification/wiki/VSS-Layers-Concept). Even if you could read VSS-version correctly, there is a risk that a layer above has added, removed or redefined signals. So in addition to VSS version one might want to get information on applied layers as well.

UlfBj commented 2 years ago

Wouldn't it make sense to have the VSS schema information somewhere available within the VISS implementation so that a client can make a preflight request to determine the available version of the schema or can download the schema from a specified interface of the VISS?

A solution that mitigates the efficiency problem mentioned in 1. is that the VISSv2 server generates the tree once, and saves it locally. When a client issues a "signal-discovery" request the server responds with the content of the previously generated file. This will however be complicated if the feature https://www.w3.org/TR/viss2-core/#scope-list is used. However, I think this is an implementation issue, the VISSv2 spec supports signal discovery requests, and VSS specifies VersionVSS.[Major|Minor|Patch|Label], which I see as making them mandatory.

So in addition to VSS version one might want to get information on applied layers as well.

I think this can be solved by using the VersionVSS.Label attribute.

aw-muc commented 2 years ago

Generating the tree on vehicle start up would be a possibility, which I did not thought about. In my current use case, where I have a backend simulating multiple different vehicles with different schema, this is more difficult but resolvable (maybe I build up the schema if i get a token request for a specific vin).

Nethertheless as mentioned above I could use the VersionVSS.[Major|Minor|Patch|Label] information within the VISS to determine the version below.

To query this information as a preflight request, would it make sense that these information are public and can be requested without an access token?

UlfBj commented 2 years ago

To query this information as a preflight request, would it make sense that these information are public and can be requested without an access token?

I think that might be a good idea. The Access control selection mechanism described in the spec supports it.

aw-muc commented 2 years ago

in this case I would add a "validate: write-only" information, within the meta-data of the VersionVSS - Node as described here Access Control Selection; In this case if the meta data is available within the model, the access control server would not block any requests for data without a token against the VersionVSS - Node? correct?

UlfBj commented 2 years ago

In this case if the meta data is available within the model, the access control server would not block any requests for data without a token against the VersionVSS - Node? correct?

Correct