Versions Compared

Old Version 13

changes.mady.by.user Daniel Alvarez

Saved on

compared with

New Version 14

changes.mady.by.user Daniel Alvarez

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

VSS modelling language requirements

The following table represents a zoomed-out view of the essential requirements that the VSS modeling language should satisfy. They are based on the different stakeholders' desires which have been collected through multiple exchanges. 

Info
If you consider that a particular criterium or aspect is missing, feel free to contribute. Bear in mind that any contribution must be framed in a collaborative way to foster community support and future adoption.
Criteria
Business
Requirement
Product Requirement
descriptionCurrent (VSPEC)Desired
Simplicity*
  • Must be human-readable.
  • Must be easily understood by Subject Matter Experts (SMEs), even when they have little to no knowledge of data modelling best practices.
  • Must be useable by new comers within a reasonable period of time (e.g., a few hours).
  • Must be easy to contribute (i.e., to extend the controlled vocabulary).

✅ Yes

✅ Yes
Technology Agnosticism*
  • Must be compatible with little effort to other artefacts and must not be a constrainer.
  • Must work with a variety of technologies

✅ Yes

Via vss-tools.

✅ Yes
Modularity*
  • Must allow the use (or contribution) of only the pieces needed.
  • Must be able to adopt only parts of the model that matter to the user.
  • Must be able to extend and override parts of the model as needed for internal and external use.

⚠️ Partly 

Specification can be split into multiple files. However, not all components are reusable (e.g., allowed values).

✅ Yes
Scalability & Maintainability*
  • Vocabulary of a domain can grow with constant effort.
  • Must support a wide variety of vehicle domains (e.g. Seating, HVAC, Entertainment, Engine, etc...).
  • Must support the re use of existing models or vocabularies.
  • Should extend beyond passenger cars (e.g., Motorcycle).

⚠️ Partly

Yes in the sense that the vocabulary of vehicle properties can be further extended. However, its expressivity is limited and covering more features requires significant work on the tools.

✅ Yes
Metadata Resource Uniqueness*
  • Elements in the domain model must provide explicit future-proof identifiers.
  • Supports versioning. 

⚠️Partly

Just the Fully-Qualified Name (fqn) and the UUID that can be constructed from the metadata are unique. Specification of a concept can appear multiple times.

✅ Yes
Support for Multiple Classification Schemes*
  • Concepts of interest in a domain model can be classified with arbitrary hierarchies.

❌No

One tree has one dimension only. Paths of the expanded tree create dependencies and moving a concept to another part in the tree is usually painful.

✅ Yes
Support for Cross Domain References*
  • Elements of the model can be re used and nested arbitrarily.

❌No

VSS tree has one dimension only. One

could have multiple trees, but (currently) each tree would continue to be an independent domain.

fixed hierarchy!

✅ Yes
Support for the Specification of Capabilities*
  • Not only the data structure is specified, but also the allowed operations on the data are formalised (e.g., API-oriented).

❌No

VSS focuses on the data structure (e.g., datatypes, units, etc.) But, no possible interactions with the specified data are formally described (e.g., Concept Seat is modeled but not the possible operations on that property).

✅ Yes
Community and Tools*
  • Must scale across Automotive and adjacent industries
  • Cost
  • Ease of Adoption
    • Ease of Contribution
    • .
    • Low development and maintenance costs.
    • Based on a well-established set of stable open-source tools.
    • Specified domain models should be usable outside COVESA.

    ❌No

    Limited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools.

    		✅ Yes

    Support for Automated Reasoning**

    • Resulting domain models could implement basic inferences. 

    ❌No

    No mechanism for semantic correctness and consistency. (e.g., what distinguishes a Car from a Motorcycle? etc.)

    ⚠️Partly

    This is a nice

    Only via add-ons.

    Other? <Add here>


    * = Must-have feature!

    ** = Nice-to-have feature

    ...

    Proposed Solutions

    ...

    that is not seen as essential by the members in COVESA. Possible limited support of it via add-ons. 

    VSS modelling language alternatives


    CriteriaVSPECGraphQLSKOS (RDF)GraphQL + SKOSUML (XMI)OMG IDLProtobufOpenAPISHACL (RDF)JSON SchemaOWL (RDF)
    Simplicity*

    ✅ Yes

    		✅ Yes⚠️ Partly ✅ Yes❌No?✅ Yes✅ Yes❌No⚠️ Verbose❌No
    Technology Agnosticism*

    ✅ Yes

    		✅ Yes⚠️ Partly ✅ Yes⚠️ Partly?❌No✅ Yes⚠️ Partly ✅ Yes❌No
    Modularity*

    ⚠️ Partly 

    		✅ Yes✅ Yes✅ Yes✅ Yes?❌No⚠️ Partly ✅ Yes✅ Yes✅ Yes
    Scalability & Maintainability*

    ⚠️ Partly

    		✅ Yes✅ Yes✅ Yes❌No?⚠️ Partly ⚠️ Partly ⚠️ Partly⚠️ Partly❌No
    Metadata Resource Uniqueness*

    ⚠️Partly

    		⚠️ Partly✅ Yes✅ Yes❌No?⚠️ Partly ⚠️ Partly ✅ Yes❌No✅ Yes
    Support for Multiple Classification Schemes*

    ❌No

    		⚠️ Partly✅ Yes✅ Yes⚠️ Partly ?❌No❌No⚠️ Partly❌No✅ Yes
    Support for Cross Domain References*

    ❌No

    		✅ Yes✅ Yes✅ Yes⚠️ Partly ?❌No❌No✅ Yes✅ Yes✅ Yes
    Support for the Specification of Capabilities*

    ❌No

    		✅ Yes❌No✅ Yes⚠️ Partly ?❌No✅ Yes❌No❌No❌No
    Community and Tools*

    ❌No

    		✅ Yes⚠️ Partly✅ Yes⚠️ Partly ?✅ Yes✅ Yes❌No✅ Yes⚠️ Partly

    Support for Automated Reasoning**

    ❌No

    ❌No

    ⚠️ Partly

    ⚠️ Partly

    ❌No

    ?

    ❌No

    ❌No

    ❌No

    ❌No

    ✅ Yes


    ...

    • VSPEC: YAML with custom syntax. Vehicle properties are organised in a single tree hierarchy. Changes in the modelling language imply significant work on the tooling
      GitHub Repository:

    ...

    • Schema Definition Language (SDL): A language for APIs. Specifies the data structure and the possible operations on the data. Elements are organised in a graph.
      https://graphql.org/learn/

    ...