Multiple and/or unclear criteria used for classifying the information in the tree

[jdacoello]

The issue

Considering the following:

• The VSS tree uses a tree-like hierarchy to define the name paths of the vehicle data points.
• A tree-like hierarchy can only cover one dimension effectively. This means that there is an implicit relationship between the branches.
• VSS is not a taxonomy - When the implicit relationship is ChildBranch --subClassOf--> ParentBranch, we are talking about a taxonomy. Therefore, it is misleading to say that VSS is a taxonomy, because it does not comply with this criteria. For example: we cannot say that a Cabin is a sub class of a Vehicle, or that the Hood is a sub class of a Body. In contrast, saying that a Car is a sub class of a Vehicle is compliant with what a taxonomy does because the Car is a more specific type of a Vehicle.
• VSS seems to be a meronymy - When the implicit relationship is ChildBranch --partOf--> ParentBranch, we are talking about a meronymy . Here is valid to say that Cabin is a part of the Vehicle, or that the Hood is part of the Body.

However, there is no clear statement in the documentation indicating the way the information is (and must be) classified. Sometimes you find paths that represent the physical distribution of the vehicle components, such as Vehicle.Cabin.Infotainment.HMI. However, there are other uses of branches as a way to group (for convenience) some data points that should appear together, such as Vehicle.VehicleIdentification.

Possible treatment

Some ideas to cope with this issue could be:

• Define ONLY ONE criteria for organising the information in the tree. For example: state that the implicit relationship between branches means ChildBranch --partOf--> ParentBranch.
• Enforce the use of this criteria in the definition of any branch.
• Use a different separator to indicate the instances.
  • For example, consider the path Vehicle.Cabin.Door.Row2.Left.IsLocked. Here Row2 is not part of the Door but it is actually one of the available doors. The same holds for Left not being part of Row2
  • To me, it makes more sense to have something like Vehicle.Cabin.Door(Row2.Left).IsLocked. Here, it is clearer that it is an instance of a Door that is part of the Cabin, which is part of the Vehicle

[erikbosch]

I would appreciate any proposal (that possibly could be added to our guidelines) on how to organize data/branches. As of today when discussed we have said that the tree structure to a big extent only intends to create unique names and make it reasonably easy to find signals, it does not intend to reflect logical deployment/ownership of data in the vehicle. I assume that if we are to have a more strict "part of"/"belongs to" approach that some significant changes would be required in our signal tree. So if we are are to change/extend guidelines it would also be good to have a summary on how it would affect current tree. If we want to do major path changes then it could possibly be a good candidate feature for VSS 5.0 (possibly planned for October this year). If we are to do major changes we could possibly discuss #527 at the same time.

When it concerns instance separators I have no "theoretical" problems changing to Vehicle.Cabin.Door(Row2.Left).IsLocked. But it would affect tooling and possibly downstream projects like VISS and KUKSA.val. In short - I do not know if parenthesis are supported as part of identifiers in Yaml, Franca, VISS, KUKSA.val and so on. So maybe changing to parenthesis is not feasible for all use-cases. But that on the other hand does not mean that we need to use the dot-notation in all use-cases. We could for instance support two types of generated JSON - one with expanded instances as today, one where instance-information is kept similar to how it is in *.vspec files. Then actual implementation could decide how it would like to represent/address signals.

For example, if you want to open a door, a programmatic API could potentially support both variants below to select the wanted door:

my_vehicle->get_cabin()->get_door(2, LEFT)->set_is_open(true)
my_vehicle->get_cabin()->get_row2->get_left()->set_is_open(true)

[jdacoello]

I used the parentheses just to show an example. So, it can basically take any other symbol that is supported. This improvement is not urgent and can be addressed for V5.0. A good starting point would be to identify all the existent implicit relationships in the current VSS. As said, it seems that the predominant one is the partOf or belongsTo relationship, where the branches refer mostly to vehicle components.

So, the questions to answer are:

• What entities do branches represent, and are they all of the same type?
• What is the implicit relationship between each branch, and is this relationship the same for the whole VSS model?

BTW, It seems that I (as contributor) cannot add a label to the issue. Can you @erikbosch please label this issue for the V5.0 release, and as an enhancement?