Branch names are not unique

[jdacoello]

During the refactoring of the GraphQL exporter, I noticed there are repeated names for branches in the specification.

Branch name only

For example, if we look at the branch name without the context path (i.e., Window vs. Vehicle.Cabin.Door.Window), we have the following duplicates:

branch_name      count
Brake            3
Identifier       3
Shade            2
Backrest         2
Lumbar           2
SideBolster      2
Headrest         2
Occupant         2
Seating          2
EngineCoolant    2

                                                            name
fqn                                                             
Vehicle.Cabin.Seat.Backrest                             Backrest
Vehicle.Cabin.Seat.Switch.Backrest                      Backrest
Vehicle.Body.Lights.Brake                                  Brake
Vehicle.Chassis.Brake                                      Brake
Vehicle.Chassis.Axle.Wheel.Brake                           Brake
Vehicle.Powertrain.CombustionEngine.EngineCoolant  EngineCoolant
Vehicle.Powertrain.ElectricMotor.EngineCoolant     EngineCoolant
Vehicle.Cabin.Seat.Headrest                             Headrest
Vehicle.Cabin.Seat.Switch.Headrest                      Headrest
Vehicle.Cabin.Seat.Occupant.Identifier                Identifier
Vehicle.Driver.Identifier                             Identifier
Vehicle.Occupant.Identifier                           Identifier
Vehicle.Cabin.Seat.Backrest.Lumbar                        Lumbar
Vehicle.Cabin.Seat.Switch.Backrest.Lumbar                 Lumbar
Vehicle.Occupant                                        Occupant
Vehicle.Cabin.Seat.Occupant                             Occupant
Vehicle.Cabin.Seat.Seating                               Seating
Vehicle.Cabin.Seat.Switch.Seating                        Seating
Vehicle.Cabin.Sunroof.Shade                                Shade
Vehicle.Cabin.Door.Shade                                   Shade
Vehicle.Cabin.Seat.Backrest.SideBolster              SideBolster
Vehicle.Cabin.Seat.Switch.Backrest.SideBolster       SideBolster

Immediate parent name + Branch name

If we consider the combination of the {inmmediate_parent_name}.{branch_name} (e.g., Door.Window instead of the full Vehicle.Cabin.Door.Window), we still have duplicate entries:

combined                count
Backrest.Lumbar         2
Backrest.SideBolster    2
Occupant.Identifier     2

                                                            combined
fqn                                                                 
Vehicle.Cabin.Seat.Backrest.Lumbar                   Backrest.Lumbar
Vehicle.Cabin.Seat.Switch.Backrest.Lumbar            Backrest.Lumbar
Vehicle.Cabin.Seat.Backrest.SideBolster         Backrest.SideBolster
Vehicle.Cabin.Seat.Switch.Backrest.SideBolster  Backrest.SideBolster
Vehicle.Cabin.Seat.Occupant.Identifier           Occupant.Identifier
Vehicle.Occupant.Identifier                      Occupant.Identifier

Proposal

I think it would be a smart move to correct that in the specification. More concretely:

• If duplicate branches convey the exact same intended meaning, then merge them.
• if duplicate branches have different intended meaning, then rename them to be more specific and to distinguish them from the others.
• Add a rule that makes it mandatory for branches to have a unique name.

As you can see, there are not too many duplicates, and the proposed change is feasible.
We can start by fixing the uniqueness in the combination {inmmediate_parent_name}.{branch_name}. Once this is resolved, we can address the uniqueness of the branch name alone.

One big advantage I see is that we can decouple the dependencies of the nodes from the whole fqn path and the concepts become easier to maintain in the long run as: FeatureOfInterest and Property. For example, modeling the window position, will be about modeling the property position of the feature of interest Window.

For example, in GraphQL, types, enums, scalars are unique within the schema. This uniqueness makes it really easy to restructure the hierarchies and define mappings to other languages.

[erikbosch]

MoM:

• Daniel presented the issue
• Sebastion Schleemilch: Could use struct in some cases
• Erik: Historically we have not requested individual segments to be unique, only full path
• Please review, continued discussion in next meeting