Remove obsolete sensor/actuator properties

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>

docs-gen/content/_index.md

@@ -3,8 +3,11 @@ title: "Vehicle Signal Specification"
 ---
 # Vehicle Signal Specification
 
-This documentation gives you an overview of the current ```Vehicle Signal
-Specification```:
+The Vehicle Signal Specification (VSS) is an initiative by [COVESA](https://www.covesa.global/) to define a syntax and a catalogue for vehicle signals.
+The source code and releases can be found in the [VSS github repository](https://github.com/COVESA/vehicle_signal_specification).
+Some tools for parsing and converting VSS files can be found in the [VSS-tools github repository](https://github.com/COVESA/vss-tools).
+
+This documentation gives you an overview of VSS:
 
 * [Introduction](/vehicle_signal_specification/introduction) </br> Read this part if you want to know more
 about what the specification is all about, what's in and out and how to quickly

docs-gen/content/introduction/overview.md

@@ -7,6 +7,11 @@ chapter: false
 
 ## What is VSS?
 The Vehicle Signal Specification introduces a domain taxonomy for vehicle signals.
+In short this means that VSS introduces:
+
+* A syntax for defining vehicle signals in a structured manner.
+* A catalogue of signals related to vehicles.
+
 It can be used as standard in automotive applications to communicate information
 around the vehicle, which is semantically well defined. It focuses on vehicle
 signals, in the sense of classical attributes, sensors and actuators with the raw data
@@ -17,22 +22,29 @@ A standardized vehicle data specification allows an industry actor to use a
 common naming space for communication and, ultimately, abstracts underlying
 vehicle implementation details.
 
-The representation of vehicle data specifications is vendor independent.
-Vendor-specific extensions can be specified in a dedicated and uncontrolled
-branch of the specification tree.
+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 be specified
+(see [Overlays](../rule_set/overlay.md).
 
-#### What's in
-* Standardized data definition for vehicle signals
-* Same semantic understanding across different domains
-* Basic definition for interfaces working on vehicle data (w3c, etc.)
+### What's in
+* Standardized data definition for vehicle signals.
+* Same semantic understanding across different domains.
+* Basic definition for interfaces working on vehicle data (w3c, etc.).
 
-#### What's out
-* Everything outside the vehicle signal domain (customer, weather, etc.)
-* Concrete interface definition
+### What's out
+* Everything outside the vehicle signal domain (customer, weather, etc.).
+* Concrete interface definition.
 
 ## Example
 The figure below shows an example snapshot of a generated tree of the
 specification. The leafs contain the actual information as shown in the figure.
 Before going into detail of the specification, let's dig deeper into taxonomies.
 
 ![Example tree](/vehicle_signal_specification/images/tree.png?classes=shadow&width=60pc)
+
+## VSS usage for other domains
+
+The VSS catalogue focuses on signals related to vehicles.
+It is not the intention of the VSS project to add signals for other domains.
+The syntax used for defining VSS signals and related tooling could however be used to define similar signal trees
+for other domains.

docs-gen/content/rule_set/_index.md

@@ -8,4 +8,18 @@ chapter: true
 
 The `Rule Set` of a [domain taxonomy](/vehicle_signal_specification/introduction/taxonomy/) is used to describe how to write the data definition syntactically.
 
-In this chapter you learn about the rule set for VSS.
+This chapter defines and describes the rule set for VSS.
+Tools in the [vss-tools repository](https://github.com/COVESA/vss-tools) can be used to validate that a specification follows the rule set for VSS,
+but those tools may have limitations and may not check all rules stated in this document.
+In case of conflict, what is stated in the rule set in this documentation is considered to have precedence over tool implementations.
+
+## Version handling
+
+The source for the rule set is in [VSS Git repository](https://github.com/COVESA/vehicle_signal_specification/tree/master/docs-gen/content).
+The online version of the rule set in the [generated VSS documentation](https://covesa.github.io/vehicle_signal_specification/)
+is updated whenever a new commit is merged to the VSS master branch and does this not necessarily correspond to the rule set for the last release VSS version.
+
+To highlight important changes to the VSS rule set two notations are used in the documen
+
+* `since version X.Y` means that the concept/syntax was introduced in version X.Y. Older tools not supporting VSS version X.Y may not support this concept/syntax.
+* `deprecated since version X.Y` means that the concept/syntax is no longer recommended from version X.Y onwards. The concept/syntax may be removed in the next major release.

docs-gen/content/rule_set/basics.md

@@ -4,16 +4,16 @@ date: 2019-08-04T13:05:11+02:00
 weight: 1
 ---
 ## Specification format
-A domain specification is written as a flat YAML list, where each signal and
-branch is a self-contained YAML list element.
 
-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 files following the rule set defined for VSS.
+They also support the use of include directives to refer to other *vspec* files, much like ```#include``` in C/C++. .
+Please note that, from a YAML perspective, the include directive is just another comment.
 
-A vspec can, in addition to a YAML list, also contain include directives.
+The file [VehicleSignalSpecification.vspec](https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/VehicleSignalSpecification.vspec) serves as root
+and includes other *vspec* files from the [VSS repository](https://github.com/COVESA/vehicle_signal_specification).
 
-An include directive refers to another vspec file that is to replace the
-directive, much like ```#include``` in C/C++. Please note that, from a YAML
-perspective, the include directive is just another comment.
+The raw specification files can with help of tools in the [vss-tools repository](https://github.com/COVESA/vss-tools) be converted to other formats that are more user friendly to read. Converted representations are also included as release artifacts for each [VSS release](https://github.com/COVESA/vehicle_signal_specification/releases).
 
 ## Addressing Nodes
 
@@ -24,32 +24,32 @@ a period ("."). The element hops from the root to the leaf is called ```path```.
 For example, the dimming status of the rearview mirror in the cabin is addressed:
 
 
-    Cabin.RearviewMirror.Dimmed
+    Vehicle.Cabin.RearviewMirror.Dimmed
 
 
 If there are an array of elements, such as door rows 1-3, they will be
 addressed with an index branch:
 
 ```
-Cabin.Door.Row1.Left.IsLocked
-Cabin.Door.Row1.Left.Window.Position
+Vehicle.Cabin.Door.Row1.Left.IsLocked
+Vehicle.Cabin.Door.Row1.Left.Window.Position
 
-Cabin.Door.Row2.Left.IsLocked
-Cabin.Door.Row2.Left.Window.Position
+Vehicle.Cabin.Door.Row2.Left.IsLocked
+Vehicle.Cabin.Door.Row2.Left.Window.Position
 
-Cabin.Door.Row3.Left.IsLocked
-Cabin.Door.Row3.Left.Window.Position
+Vehicle.Cabin.Door.Row3.Left.IsLocked
+Vehicle.Cabin.Door.Row3.Left.Window.Position
 ```
 
 In a similar fashion, seats are located by row and their left-to-right position.
 
 ```
-Cabin.Seat.Row1.Pos1.IsBelted  # Left front seat
-Cabin.Seat.Row1.Pos2.IsBelted  # Right front seat
+Vehicle.Cabin.Seat.Row1.Pos1.IsBelted  # Left front seat
+Vehicle.Cabin.Seat.Row1.Pos2.IsBelted  # Right front seat
 
-Cabin.Seat.Row2.Pos1.IsBelted  # Left rear seat
-Cabin.Seat.Row2.Pos2.IsBelted  # Middle rear seat
-Cabin.Seat.Row2.Pos3.IsBelted  # Right rear seat
+Vehicle.Cabin.Seat.Row2.Pos1.IsBelted  # Left rear seat
+Vehicle.Cabin.Seat.Row2.Pos2.IsBelted  # Middle rear seat
+Vehicle.Cabin.Seat.Row2.Pos3.IsBelted  # Right rear seat
 ```
 
 The exact use of ```PosX``` elements and how they correlate to actual
@@ -61,11 +61,12 @@ If a new leaf node is defined, all parent branches included in its name must
 be included as well, as shown below:
 
 ```
-[Signal] Cabin.Door.Row1.Left.IsLocked
-[Branch] Cabin.Door.Row1.Left
-[Branch] Cabin.Door.Row1
-[Branch] Cabin.Door
-[Branch] Cabin
+[Signal] Vehicle.Cabin.Door.Row1.Left.IsLocked
+[Branch] Vehicle.Cabin.Door.Row1.Left
+[Branch] Vehicle.Cabin.Door.Row1
+[Branch] Vehicle.Cabin.Door
+[Branch] Vehicle.Cabin
+[Branch] Vehicle
 ```
 
 The branches do not have to be defined in any specific order as long
@@ -81,13 +82,13 @@ changes, the original nodes are marked as deprecated with the following rules.
 * Nodes, which are moved in the tree or are intended to be removed from the specification are marked with the deprecation keyword.
 * The string following the deprecation keyword shall start with the version, when the node was deprecated starting with `V` (e.g. `V2.1`) followed by the reason for deprecation.
 * If the node was moved, it shall be indicated by `moved to` followed by the new node name in dot notation as deprecation reason. This keyword shall be used only
-if the meta-data of the moved node hasn't changed. 
+if the meta-data of the moved node hasn't changed.
 * If the node is intended to be removed from the specification or the meta data changed, it shall be indicated by `removed` and optionally the reason for the removal as deprecation reason.
 * Nodes which are deprecated will be removed from the specification, either in the second minor update or, if earlier, the next major update.
 
 ### Example
 ```YAML
-Navigation.CurrentLocation:
+Vehicle.Navigation.CurrentLocation:
   type: branch
   description: The current latitude and longitude of the vehicle.
   deprecation: V2.1 moved to Vehicle.CurrentLocation
@@ -108,7 +109,7 @@ Examples:
 
 ```
 SomeBranch.AnotherBranch.MySignalName
-Cabin.Door.Row1.Left.IsLocked
+Vehicle.Cabin.Door.Row1.Left.IsLocked
 ```
 Naming convention for string literals can be found in the [chapter](/vehicle_signal_specification/rule_set/data_entry/allowed)for specifying allowed values.
 

docs-gen/content/rule_set/data_entry/sensor_actuator.md

@@ -63,8 +63,14 @@ The unit of measurement that the data entry has. See [Unit
 Type](data_unit_types/) chapter for a list of available unit types. This
 cannot be specified if ```allowed``` is defined as the signal type.
 
-**```sensor```** *[optional]*  
+**```sensor```** *[optional]* `deprecated since version 3.1`
 The sensing appliance used to produce the data entry.
 
-**```actuator```** *[optional]*  
+*The VSS signal metadata attributes `sensor` and `actuator` are no longer considered part of the core VSS syntax*
+*If needed, they shall be used as additional metadata, see [overlays](../overlay.md) *
+
+**```actuator```** *[optional]* `deprecated since version 3.1`
 The actuating appliance consuming the data entry.
+
+*The VSS signal metadata attributes `sensor` and `actuator` are no longer considered part of the core VSS syntax*
+*If needed, they shall be used as additional metadata, see [overlays](../overlay.md) *