Apply suggestions from code review

Co-authored-by: Thomas Sedlmayer <tsedlmayer@pmsfit.de>
Signed-off-by: Pierre R. Mai <pmai@pmsf.de>

doc/architecture/trace_file_formats.adoc

@@ -68,43 +68,40 @@ Rather, it indicates the version of the OSI trace file format itself.
 
 `min_osi_version`::
 The minimum version of the OSI schema used in the trace file OSI channels.
-This is a string in the format `major.minor.patch`, for example `3.0.0`.
+This is a string in the format `major.minor.patch`, for example `3.4.0`.
 
 `max_osi_version`::
 The maximum version of the OSI schema used in the trace file OSI channels.
-This is a string in the format `major.minor.patch`, for example `3.0.0`.
+This is a string in the format `major.minor.patch`, for example `3.7.0`.
 
 `min_protobuf_version`::
 The version of the protobuf implementation used in the trace file.
 This is a string in the format `major.minor.patch`, for example `3.17.3`.
 
 `max_protobuf_version`::
 The version of the protobuf implementation used in the trace file.
-This is a string in the format `major.minor.patch`, for example `3.17.3`.
+This is a string in the format `major.minor.patch`, for example `3.26.0`.
 
 `zero_time`::
-The point in time corresponding to time 0 in all timestamps in the trace file.
+The point in real or simulated calendar time corresponding to time 0 in all timestamps in the trace file.
 Must be provided as a full ISO8601 formatted date time string, including timezone data, conforming to the https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp[XML Schema dateTimeStamp] lexical space.
 Values must match the following regular expression:
 `-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))`
 +
-NOTE: that even in pure simulation use cases there is usually a relationship to real time, as on-board components and environment simulation have necessary relationships to real time (for example, the embedded `HostVehicleData` will carry relevant real time information, for localization and other purposes).
+NOTE: Even in pure simulation use cases there is usually a relationship to a simulated calendar time, as on-board components and environment simulation have necessary relationships to a simulated calendar time (for example, the embedded `HostVehicleData` will carry relevant simulated calendar time information, for localization and other purposes).
 
 `creation_time`::
-The point in time when the trace file was created.
+The point in real calendar time when the recording of the data in the trace file was started.
 Must be provided as a full ISO8601 formatted date time string, including timezone data, conforming to the https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp[XML Schema dateTimeStamp] lexical space.
 
 The `net.asam.osi.trace` meta-data record may also contain the following recommended `metadata` entries:
 
 `description`::
 A human-readable description of the data contained in the multi channel trace file.
 
-`creator`::
+`authors`::
 A list separated by commas of entities (not tools) involved in the creation of the data contained in the file.
 
-`license`::
-If the contents of the file is licensed under any SPDX registered license, this entry should contain the SPDX identifier for the license.
-
 `data_sources`::
 A list separated by commas of data sources used in the creation of the data contained in the file.
 
@@ -123,7 +120,8 @@ The schema record must contain the following fields:
 A file-wide unique non-zero identifier for the schema record.
 
 `name`::
-The fully qualified name to the message within the OSI descriptor set. For example, for the `SensorView` message type, this would be `osi3.SensorView`.
+The fully qualified name to the message within the OSI descriptor set.
+For example, for the `SensorView` message type, this would be `osi3.SensorView`.
 
 `encoding`::
 The value `protobuf`.
@@ -149,8 +147,8 @@ The ID of the schema record that describes the message type of the channel.
 
 `topic`::
 A unique name for the channel within the trace file.
-When recording OSI traces for a model packaged according to the OSI Sensor Model Packaging (OSMP) layer, using the naming conventions defined in the OSMP specification for variables as topics is recommended.
-For example, for a sensor model with two SensorView inputs and one SensorData output, the topic names would be `OSMPSensorViewIn[1]`, `OSMPSensorViewIn[2]`, and `OSMPSensorDataOut`, accordingly.
+When recording OSI traces for a model packaged according to the OSI Sensor Model Packaging (OSMP) layer, using the naming conventions defined in the OSMP specification for variables as topics is recommended, potentially with a suitable added prefix for disambiguation.
+For example, for a sensor model named RadarSensorFL with two SensorView inputs and one SensorData output, the topic names would be `RadarSensorFL.OSMPSensorViewIn[1]`, `RadarSensorFL.OSMPSensorViewIn[2]`, and `RadarSensorFL.OSMPSensorDataOut`, accordingly.
 In other cases, the topic name should be chosen to reflect the purpose of the channel, and should include some indication of the message type.
 
 `message_encoding`::
@@ -192,8 +190,8 @@ Otherwise this should be set to zero to indicate that no reliable sequence numbe
 `log_time`::
 This field is in nanoseconds and uses the same epoch as the `publish_time` field.
 It is used to determine the order of messages in the trace file, and provides for time-based random access to the data streams.
-Unless there is a specific reason to set this field to a different value, it should be set to the same value as `publish_time`, as this reflects the time flow as reflected in the OSI message stream.
-Only if recreation of the message stream with actual message transmission times is required - for example for asynchronous packaging layers, this field should be set to the time when the message was enqueued for addition to the trace file.
+Unless there is a specific reason to set this field to a different value, it should be set to the same value as `publish_time`, as this reflects the time flow of the OSI message stream.
+Only if recreation of the message stream with actual message transmission times is required, for example for asynchronous packaging layers, this field should be set to the simulation time when the message was enqueued for addition to the trace file.
 
 `publish_time`::
 The timestamp taken from the timestamp field of the stored OSI top-level message.