vehicle_signal_specification icon indicating copy to clipboard operation
vehicle_signal_specification copied to clipboard

:construction: Model, structs, branches and the world

Open sschleemilch opened this issue 5 months ago • 3 comments

I was thinking recently a lot about structs and branches. Especially about how they differ. In general I would say that structs are pretty much the same as branches but just a different tree entry point (Types). If we exchange struct with branch and property with just a normal child having a datatype then we have the same as modelling it in the initial tree. Only difference like I said is having a separate Tree for it.

Also in context of https://github.com/COVESA/vss-tools/pull/405 I noticed that in terms of types there is no difference in modelling it as a struct or as a branch.

Essentially it leads to the fact that we could model everything using structs and multiple root elements in one or several yaml files. It then is just someting similar to a class diagram. In the same run we would get rid of needing for includes as well as instances. Two features that are often discussed. I did not think this completely until then end but I wanted to share my thoughts.

Here is an example model of some elements that just came into my mind. The only downside I can see for now is that you cannot directly reference list elements (Vehicle.Cabin.Door.Row1.PassengerSide) Maybe this is the crucial point where VSS shines but I am not sure how much we gain with that.

Example:

Vehicle:
  type: struct
  description: Vehicle

Vehicle.Cabin:
  type: property
  description: Cabin
  datatype: Cabin

Vehicle.Speed:
  type: property
  description: Speed
  datatype: uint16

Cabin:
  type: struct
  description: Cabin

Cabin.Doors:
  type: property
  description: Door
  datatype: Door[]

Door:
  type: struct
  description: Door

Door.Position:
  type: property
  description: Door Position
  datatype: string
  allowed:
  - Row[1,2]
  - "[Driver, Passenger]Side"

Door.Window:
  type: property
  description: Window
  datatype: Window

Window:
  type: struct
  description: Window

Window.Position:
  type: property
  datatype: uint8
  description: Percentage of position
  min: 0
  max: 100

Like I said, all definitions could be sharded across different files and all you need to know is the entrypoint. So an example cli call for this imaginary construct would be:

vspec export foo --model main.vspec --model cabin.vspec --model  door.vspec --entry Vehicle

Of course the cli call could get quite long doing it like that but we could have just a config file for instance. The question is if yaml is then still the right tool for the job. I think it goes into the same direction that has been discussed already a bit regarding modelling vss with GraphQL.

This would align quite well with programming languages where you can have roughly a file for each class. What we would have in the end is a language agnostic model of something. This would not be at all limited to Vehicle anymore (I know, the current solution also would work just fine with other root node names).

Anyway, I just wanted to share that thought as I myself struggled a bit with the struct/branch difference and when to apply what.

:clinking_glasses:

sschleemilch avatar Sep 16 '24 18:09 sschleemilch