Information about underlying VSS model incl. schema about automotive HOT 6 CLOSED

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.

from automotive.

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.

from automotive.

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?

from automotive.

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.

from automotive.

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?

from automotive.

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

from automotive.