VSC - Common Interface Description Model

Goal/purpose

Repeat the idea of VSS (proposed data-description-standard, and proposed standard-catalog of data), to propose a standard interface/service description language for use with standard-catalog of services, but also to describe all other types of interface definition.  One common interface language.

Meeting information

• We are in the process of setting up a new meeting structure in WebEx and/or Zoom

TODO: also link from git repo to the meeting info.  Github wiki is used for VSS, do similarly for this 

Ongoing design/discussion points

For details it could be best to track the GitHub issues in VSC and VSC-tools

• Stakeholder input:  #1 preferred source-language for interface descriptions.  e.g. Franca IDL or other, or do companies use gRPC directly, etc.?
• Stakeholder input:  Interesting mapped technologies, input-and-output formats and bindings.  (e.g. gRPC, SOME/IP, DDS, HTTP/REST based remote procedure call protocols, ...)
• How to reference VSS signals in VSC model
• Error handling feature built in
  • Build in some support for success/error return
  • Note: Method invocation errors that are related to the particular target/protocol are separate from this mechanism.  Those are defined in target/protocol separate specification. 
    Example: "method name not found" on a web request.
  • Support a global error type enum.  Configurable.  More than one.
  • Specify which errors are expected/applicable per method
  • Error feature is optional but best-practice.  Out-parameters still exist of course, and can be (mis)used to report invocation success
  • Next:  Make syntax proposal.  Consider is this feature reasonable to translate/map to all IDLs, target environments that we envision.  How is it mapped?
• Franca <-> VSC YAML mapping 
  • document, compare keywords
• Franca further development to a "next version"? 
  • Interesting if desired new features are not covered.  E.g. error-feature might be one such thing.
• Set up documentation on GitHub Wiki instead, or as a complement
• Terminology, names.  Coin a useful name for the "VSC IDL language"
• Review OpenAPI, AsyncAPI, gRPC/protobuf, Franca, etc. for syntax similarity  (names of things) and feature coverage.  Find alignment oppportunities.
  • One stakeholder suggested: Could OpenAPI be extended to cover non-REST.  I.e. "OpenAPI-next" == VSC language?  Rationale: OpenAPI known outside automotive.

Frequently Asked Questions:

• Why another IDL?
• Why is adopting <insert existing choice> not enough?  Or is it?Several answers can be found in previous presentations/slide decks 

References, previous presentations...

• COVESA All Member Meeting