Minor refactoring for clarity and portability

Signed-off-by: Pierre R. Mai <pmai@pmsf.de>

Author: pmai

doc/misc/example.adoc

@@ -1,7 +1,7 @@
-= Example: Simple sensor-model FMU
+= Example: Simple sensor model FMU
 
 Then following example shows the content of a `modelDescription.xml` file that satisfies the requirements of OSMP.
-The example describes a sensor-model FMU with one input, one output, and no additional features:
+The example describes a sensor model FMU with one input, one output, and no additional features:
 
 [source]
 ----

doc/setup/build_install_example.adoc

@@ -3,10 +3,10 @@
 OSMP includes three examples located in `_osmp_/examples`:
 
 `OSMPDummySensor/`::
-Can be used as a simple dummy sensor model, demonstrating the use of OSI for sensor models consuming sensor-view data and generating sensor-data output.
+Can be used as a simple dummy sensor model, demonstrating the use of OSI for sensor models consuming sensor view data and generating sensor data output.
 
 `OSMPDummySource/`::
-Can be used as a simple source of sensor-view data and ground-truth data.
+Can be used as a simple source of sensor view data and ground-truth data.
 It can be connected to the input of an `OSMPDummySensor` model, for simple testing and demonstration purposes.
 
 `OSMPCNetworkProxy/`::
@@ -68,16 +68,9 @@ cd build
 cmake ..
 ----
 +
-. Run _make_.
+. Run _cmake_ build.
 +
 [source]
 ----
-make
-----
-+
-. Install the examples.
-+
-[source]
-----
-sudo make install
+cmake --build .
 ----

doc/spec/sensor_view_input_configuration.adoc

@@ -15,7 +15,7 @@ Sensor view input configurations shall be named with the following prefix:
 OSMPSensorViewInConfig
 ----
 
-Sensor view input-configuration requests shall be named with the following prefix:
+Sensor view input configuration requests shall be named with the following prefix:
 
 [source]
 ----

doc/spec/traffic_update_outputs.adoc

@@ -1,6 +1,6 @@
 = Traffic update outputs
 
-Traffic-update outputs are present in traffic participant models.
+Traffic update outputs are present in traffic participant models.
 
 **Prefix**
 
@@ -13,10 +13,10 @@ Traffic update outputs shall be named with the following prefix:
 
 **Rules**
 
-* If only one traffic-update output is configured, the prefix shall only be `OSMPTrafficUpdateOut`. 
-* If more than one traffic-update output is configured, the prefix shall be extended by an array index, for example `OSMPTrafficUpdateOut[1]` and `OSMPTrafficUpdateOut[2]`. 
+* If only one traffic update output is configured, the prefix shall only be `OSMPTrafficUpdateOut`.
+* If more than one traffic update output is configured, the prefix shall be extended by an array index, for example `OSMPTrafficUpdateOut[1]` and `OSMPTrafficUpdateOut[2]`.
 * Array indices shall start at 1 and shall be consecutive.
-* Each traffic-update output shall be defined as a notional discrete binary output variable with a `@causality="output"` and a `@variability="discrete"`.
+* Each traffic update output shall be defined as a notional discrete binary output variable with a `@causality="output"` and a `@variability="discrete"`.
 * The MIME type of the variable shall specify the `type=TrafficUpdate` as part of the MIME type parameters.
 * Traffic updates shall be encoded as `osi3::TrafficUpdate`.
-* The guaranteed lifetime of the traffic-update protocol-buffer pointer provided as output by the FMU shall be from the end of the call to `fmi2DoStep` that calculated this buffer until the beginning of the second `fmi2DoStep` call after that.
+* The guaranteed lifetime of the traffic update protocol-buffer pointer provided as output by the FMU shall be from the end of the call to `fmi2DoStep` that calculated this buffer until the beginning of the second `fmi2DoStep` call after that.