Changing documentation so attribute is considered a signal.

Previously we stated that only sensors and actuators were signals.

Fixes #398

docs-gen/content/ecosystem/software.md

@@ -7,7 +7,7 @@ weight: 3
 Various software frameworks exist to work with VSS data. If something is missing here, please [open an issue](https://github.com/covesa/vehicle_signal_specification/issues) and tell us.
 
 ### W3C VISS2 reference server
-A reference server written in Go for the VISSv2 specification can be found at [https://github.com/UlfBj/W3C_VehicleSignalInterfaceImpl](https://github.com/UlfBj/W3C_VehicleSignalInterfaceImpl).
+A reference server written in Go for the VISSv2 specification can be found at [https://github.com/w3c/automotive-viss2](https://github.com/w3c/automotive-viss2).
 
 ### KUKSA.val in-vehicle VISS server
 A VISS server written in C++, optimized for containerized deployments on vehicle computers is provided by the [KUKSA project](https://github.com/eclipse/kuksa.val).

docs-gen/content/introduction/overview.md

@@ -9,7 +9,7 @@ chapter: false
 The Vehicle Signal Specification introduces a domain taxonomy for vehicle signals.
 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 sensors and actuators with the raw data
+signals, in the sense of classical attributes, sensors and actuators with the raw data
 communicated over vehicle buses and data which is more commonly associated with
 the infotainment system alike.
 

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

@@ -7,9 +7,9 @@ weight: 2
 
 # Data Entry
 Leaf nodes of the tree contain metadata describing the data associated to the node.
-In order to help application developers, who are using the specification, it makes a distinction between signals - in the following as [```sensor```](/vehicle_signal_specification/rule_set/data_entry/sensor_actuator) and [```actuator```](/vehicle_signal_specification/rule_set/data_entry/sensor_actuator) - and [```attribute```](/vehicle_signal_specification/rule_set/data_entry/attributes).
-The difference between a signal and an attribute is that the signal has
-a publisher (or producer) that continuously updates the signal value while an
+In order to help application developers, who are using the specification, it makes a distinction between three types of signals - [```sensor```](/vehicle_signal_specification/rule_set/data_entry/sensor_actuator), [```actuator```](/vehicle_signal_specification/rule_set/data_entry/sensor_actuator) - and [```attribute```](/vehicle_signal_specification/rule_set/data_entry/attributes).
+The difference between sensors/actuators and attributes is that sensors/actuators typically have
+a publisher (or producer) that updates the signal value continuously when a change occur while an
 attribute has a set value that should typically not change more than once per ignition cycle.
 
 Examples and more information you'll find in the [Sensors & Actuators chapter](/vehicle_signal_specification/rule_set/data_entry/sensor_actuator) and [Attributes chapter](/vehicle_signal_specification/rule_set/data_entry/attributes).

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

@@ -6,16 +6,16 @@ weight: 4
 
 An attribute is an entity that has a  default value, specified by
 its ```default``` member.
-The standard Vehicle Signal Specification include default values for most attributes. 
-It is expected that these default values do not fit all values.
-This means that an OEM must override the standard default values if a vehicle needs a different value.
+The standard Vehicle Signal Specification does not include default values for all attributes.
+If a default value has not been specified then the OEM must define a default value matching the actual vehicle.
+If the standard defines a default value but it does not fit the actual vehicle,
+then the OEM must override the standard default value.
 
 Attribute values can also change, similar to sensor values.
 The latter can be useful for attribute values that are likely to change during the lifetime of the vehicle.
 However, attribute values should typically not change more than once per ignition cycle,
 or else it should be defined as a sensor instead.
 
-
 Below is an example of a complete attribute describing engine power
 
 ```YAML

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

@@ -4,7 +4,7 @@ date: 2019-08-04T12:37:03+02:00
 weight: 3
 ---
 
-Sensors are signals to read values of properties in a vehicle. Values of signals typically change over time. Reading a sensor shall return the current actual value of the related property, e.g. the current speed or the current position of the seat. 
+Sensors are signals to read values of properties in a vehicle. Values of sensors typically change over time. Reading a sensor shall return the current actual value of the related property, e.g. the current speed or the current position of the seat. 
 
 Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.
 
@@ -32,7 +32,7 @@ Defines the type of the node. This can be `branch`,
 
 **```datatype```**  
 The string value of the type specifies the scalar type of the data entry
-value. See [data type](#data-type) chapter for a list of available types.
+value. See [data type](data_types/) chapter for a list of available types.
 
 **```description```**  
 Describes the meaning and content of the signal.
@@ -60,7 +60,7 @@ Cannot be specified if ```allowed``` is defined for the same data entry.
 
 **```unit```** *[optional]*    
 The unit of measurement that the data entry has. See [Unit
-Type](#data-unit-type) chapter for a list of available unit types. This
+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]*  

docs-gen/content/rule_set/includes.md

@@ -41,7 +41,7 @@ included file will override the previous specifications.
 
 
 ## REUSING SIGNAL TREES
-Complete subtrees of signals and attributes can be reused by including
+Complete subtrees of signals can be reused by including
 them multiple times, attaching them to different branches each time
 they are included.
 

docs-gen/content/rule_set/private_branch.md

@@ -38,7 +38,7 @@ element as an enumerated value
 
 ## DECLARING VS. DEFINING ATTRIBUTES
 The signal extension mechanism described above is also used to declare
-an attribute in one vspec file and define it in another.  This is used
+an attribute in one vspec file and define it in another. This is used
 to setup a attribute structure standard in the core specification that
 is to be defined on a per-deployment (vehicle) basis.