Skip to content

Proposal "struct": Extend VSS to model structs Option 2

Sebastian Schildt edited this page Jul 25, 2022 · 1 revision

This extends/modifies https://github.com/COVESA/vehicle_signal_specification/wiki/Proposal-%22struct%22:--Extend-VSS-to-model-structs

to "dis-entagle" VSS tree spec from datatype definition in input

In the current model "type" represents what I think can be referred to as "data sources", except for "branch" which is a construct to support tree structures. In the proposal above "type" is extended with "struct" and "item", which I think is rather "datatype" metadata. The leads in my view to loss of clarity of the model. The parsing of the tree becomes more complex as there will be dependencies between nodes, and it is unclear what will be the result of accessing some of the nodes.

I would like to propose an alternative design that extends the "datatype" with the values "struct" and "struct[]", which when used MUST then be accompanied in the same node with the "struct" definition.

An attempt to apply it to the example from above could look something like below.

Vehicle.ADAS.Lidar.ObstacleList:
    type: sensor
    datatype: struct[]
    struct:
        id: int64
        probability: float
    ....

The datatype definition of a node is contained within that node. The "type" metadata stays unchanged. It should be possible to extend the model above so that nested structs would be supported. Syntax proposals are welcome.

A challenge in this proposal is "reusability" of such a struct defintion.