Multi-level / Hierarchical meta-data format

[gunnarx]

Some examples were described on this wiki page that discusses mapping VSS to Android Automotive properties.

In that page there are two proposals. One of them shows a single-level metadata (which is what the standard VSS currently have) e.g.

- Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure
      aospId: VehicleProperty::TIRE_PRESSURE
      aospArea: VehicleAreaWheel::RIGHT_FRONT

Noteworthy here is that metadata names have a naming convention -> in this case the prefix "aosp" on each name, to make sure it is unique, and to show what it relates to.

Further down the page is a multi-level / hierarchical metadata format that would put information under a kind of "heading" or namespace.

- Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
      AOSP:
          version: 2.0
          package: android.hardware.automotive.vehicle
          id: VehicleProperty::TIRE_PRESSURE
          area: VehicleAreaWheel::LEFT_FRONT     

      ANY_OTHER_OPERATING_SYSTEM_OR_IPC:
          version: 1.0
          package: com.oem.foo
          other_data_for_translation: true

In this case, since it is namespaced, the metadata items can have simpler names and still not collide with other usages.

The question therefore is: Should we recommend, and should the tools support, the use of this hierarchical method for metadata or should the VSS model require all metadata to be on the toplevel only. Note that this is a policy decision that affects the standard VSS catalog of data, but also rules/recommendation for any other data defined in proprietary catalogs or layers.

[barbieri]

@gunnarx as said in the call, in our internal tests we started with something that resembles the first approach, but it made things harder to implement and also manually read/write. Then we moved to the second approach.

Currently we don't have any use case to use 2 different specifications in the same node (as AOSP and ANY_OTHER_OPERATING_SYSTEM_OR_IPC), but we do have many uses for both of them in the same schema. For instance we have parts mapping to CommonAPI, parts are in other protocols (ex: MQTT), while others are plain constants that were not served by any service (if we don't have them, we'd be left to create a "fake" service to serve them using CommonAPI).

In case many of them are specified, I believe is okay for the platform to decide which one to pick (ie: by availability, by specification order)

[erikbosch]

I am doing some cleanup closing all issues created 2021 or earlier where there have been no activity 2023 or later. If you still consider this issue relevant feel free to reopen it add and add a comment on how you would like to see progress on this one.