Proposal "struct": Reference external IDLs

Instead of (re-)inventing a new IDL in terms of VSS, it might be more useful to make use of the many options already available

This are there examples of t might look life, if we allow some URI-like schema in VSS datatypes:

ADAS.Lidar.Front
    type: branch

ADAS.Lidar.Front.ObstacleList
    type: sensor  
    datatype: jsonchema://datatypes/ObstacleList.json

or

ADAS.Lidar.Front.ObstacleList
    type: sensor  
    datatype: proto://datatypes/ObstacleList.proto

or

ADAS.Lidar.Front.ObstacleList
    type: sensor  
    datatype: ros2://datatypes/ObstacleList.msg

an in case of the ROS2 example having

ObstacleList.msg

Obstacle[] obstaclelist

and Obstacle.msg

int64 id
float64 double

similar for jsonschema, ARXML Franka, you-name it

Advantages

• Can use strong tooling for various IDLs
• Extensibility in terms of supporting standard IDL specifications
• Does not "clutter" the VSS spec

Disadvantages

• Easy for our tooling, (much) harder for downstream stacks, e.g. when using a VISS system jsonchema described data might be natural to handle, protobuf is maybe harder. Also, if this is open, how would you ever handle datatype:neverseenbfore://bla
• There is a chance that the primitive data types in external IDL specifications will mismatch with the primitive data types within VSS. For example, protobuf has some fixed length types and bytes type that are not available in VSS. Similarly, JSON schema type system is different from that of VSS.
• Subsequently, VSS primitives will have to maintain parity with the primitives of whatever IDLs we want to support, adding to the effort and complexity of supporting additional IDLs
• Relying on external IDL specifications to completely parse the VSS tree. (VSS will no longer be self-sufficient). vss-tools and any custom VSS parsers out there will now have to rely on these external specification tools as well.

Neutral

• might lead to "hollowing out" VSS where people just hang their favorite data model somewhere in the tree. Depending where you stand that might be "ok" or "bad"
• Would we allow more than one IDL specification in a tree? For example, can a user use protobuf data type for one sensor, jsonschema for another, etc. ? If not, we would need additional validation to ensure only IDL specification is used across the VSS tree