Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove obsolete sensor/actuator properties #485

Merged
merged 1 commit into from
Sep 6, 2022

Conversation

erikbosch
Copy link
Collaborator

They have never been used and are not supported in tools.
Better to reintroduce them if/when we in VSS specifies recommended
additional properties for e.g. security purposes or protocol adoptions.

Fixes #302

Signed-off-by: Erik Jaegervall erik.jaegervall@se.bosch.com

@erikbosch
Copy link
Collaborator Author

Meeting discussion:

  • Possibly mark them as deprecated, refer to use overlays instead, instead and remove them first in 4.0
  • Add a few lines in documentation that the documentation is the "source of truth", not tooling.

@erikbosch
Copy link
Collaborator Author

Updated the files based on the discussion on last meeting

In short this means that VSS introduces:

* A syntax for defining vehicle signals in a structured manner
* A catalogue of signals related to vehicles.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

punctuation inconsistent

@@ -19,14 +24,14 @@ vehicle implementation details.

The representation of vehicle data specifications is vendor independent.
Vendor-specific extensions can be specified in a dedicated and uncontrolled
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove "a" if it is "branch_es"

Not a big fan of the orignial text anyway, Maybe it is already to specific here and "uncontrolled" sounds not so good

Maybe something like

"While the data in the VSS standard catalogue aims to be vendor-independent, vendor specific extensions and adaptations complying with the VSS syntax rules can an be specified (see Overlays)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current documentation is quite academic, talking about taxonomies, domains and rule sets. We could discuss if we want to refactor it to make it more "practical"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing to your proposal


## VSS usage for other domains

The VSS catalogue focus on signals related to vehicles.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

focusses?


The YAML list is a single file, called a *vspec* file.
The Vehicle Signal Specification domain specification consist of *vspec* files.
*vspec* files are YAML lists following the rule set defined for VSS.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are not "lists" anymore. "vspec files are YAML files" or "vspec files contain YAML defintions following..."

They have never been used and are not supported in tools.
Better to reintroduce them if/when we in VSS specifies recommended
additional properties for e.g. security purposes or protocol adoptions.

Also improving documentation based on PR review.

Fixes COVESA#302

Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com>
@adobekan adobekan merged commit efbb01c into COVESA:master Sep 6, 2022
@erikbosch erikbosch deleted the erikbosch/erik_opt branch February 22, 2023 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use of optional sensor and actuator attributes
3 participants