Namespace/Service structure for standardized services

[erikbosch]

There are some ideas on importing/integrating VSS into VSC. Then comes the question up on how to name services/namespaces. If we take our current service as example:

https://github.com/GENIVI/vehicle_service_catalog/blob/master/comfort-service.yml

• The service is called "comfort"
• The namespace is called "seats"

But in VSS we have today for seat-related signals paths like Vehicle.Cabin.Seat.Row1.Pos1. If we would like to integrate/import VSS into VSC we have two options:

• Make sure that services and signals referring to the same feature (e.g. a seat) exist in the same logical location. I.e. the method current_position shall exist in the same service/namespace as the VSS signal lumbar
• Logical separation, e.g. by retaining existing VSS-paths in a separate VSC service.

I could see a value if we could have a representation where logically related services and signals when imported to VSC reside in the same service or at least in the same namespace. So that if you in the future a generated API/SDK easily could find all signals and methods available for your seat.

Have there been any thoughts on how to best structure services and namespaces in VSC? Naming conventions and similar?

[gunnarx]

There are now some proposals for IFEX/VSS interoperability.

I am a little bit unsure if this ticket has thoughts related to the creation of the service catalog, or if it is primarily technical/language definition related and shall be transferred completely to IFEX development.