Adjust wording to current normative modal verbs

Signed-off-by: Pierre R. Mai <[email protected]>

Author: pmai

doc/architecture/trace_file_formats.adoc

@@ -46,13 +46,13 @@ Therefore, it can be used with any or an empty profile field in the MCAP header
 The following rules apply to OSI multi channel trace files:
 
 - The file extension to be used is `.mcap`.
-- The file must be a valid MCAP file according to the https://mcap.dev/spec[MCAP format specification] version `0x30`.
-- The file must be an indexed MCAP file, including chunk index records in the summary section, with all message records written into chunk records.
-- Chunk records must either be uncompressed or compressed using either the `zstd` or `lz4` compression algorithms.
-- The file must contain a meta-data record with the OSI trace file meta-data defined in section <<sec-osi-trace-file-multi-global-meta-data>>.
+- The file shall be a valid MCAP file according to the https://mcap.dev/spec[MCAP format specification] version `0x30`.
+- The file shall be an indexed MCAP file, including chunk index records in the summary section, with all message records written into chunk records.
+- Chunk records shall either be uncompressed or compressed using either the `zstd` or `lz4` compression algorithms.
+- The file shall contain a meta-data record with the OSI trace file meta-data defined in section <<sec-osi-trace-file-multi-global-meta-data>>.
   This meta-data record identifies the file as an OSI multi channel trace file.
-- The file must contain a schema record in the summary section for each top-level message type that is used in one or more OSI channels with the OSI message schema as defined in section <<sec-osi-trace-file-multi-schema-record>>.
-- The file must contain at least one OSI message stream in a channel as defined in section <<sec-osi-trace-file-multi-channel>>.
+- The file shall contain a schema record in the summary section for each top-level message type that is used in one or more OSI channels with the OSI message schema as defined in section <<sec-osi-trace-file-multi-schema-record>>.
+- The file shall contain at least one OSI message stream in a channel as defined in section <<sec-osi-trace-file-multi-channel>>.
 - The file may contain additional non-OSI message streams in other channels.
 
 NOTE: All OSI and non-OSI message streams stored in the same file share a common time base.
@@ -61,7 +61,7 @@ Storing of unrelated message streams in one trace file is therefore not generall
 [#sec-osi-trace-file-multi-global-meta-data]
 === Multi channel trace file global meta-data
 
-The file must contain exactly one meta-data record with the `name` field being `net.asam.osi.trace` and the following mandatory `metadata` entries:
+The file shall contain exactly one meta-data record with the `name` field being `net.asam.osi.trace` and the following mandatory `metadata` entries:
 
 `version`::
 The semantic version number of the OSI release that this OSI trace file conforms to.
@@ -89,15 +89,15 @@ The `net.asam.osi.trace` meta-data record may also contain the following recomme
 
 `zero_time`::
 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:
+This shall 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 shall 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: 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 real calendar time when the recording of the data in the trace file was started, e.g. when the recording system began writing the data to a 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.
+This shall 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.
 
 `description`::
 A human-readable description of the data contained in the multi channel trace file.
@@ -114,10 +114,10 @@ It is strongly recommended to follow reverse domain name notation for custom met
 [#sec-osi-trace-file-multi-schema-record]
 === OSI message schema
 
-For each OSI top-level message type that is used in one or more OSI channels, the OSI multi channel trace file must contain a corresponding schema record in the summary section.
-Note that if multiple versions of the OSI schema are used in the same trace file, a schema record must be included for each version, with different schema IDs.
+For each OSI top-level message type that is used in one or more OSI channels, the OSI multi channel trace file shall contain a corresponding schema record in the summary section.
+Note that if multiple versions of the OSI schema are used in the same trace file, a schema record shall be included for each version, with different schema IDs.
 
-The schema record must contain the following fields:
+The schema record shall contain the following fields:
 
 `id`::
 A file-wide unique non-zero identifier for the schema record.
@@ -132,7 +132,7 @@ The value `protobuf`.
 `data`::
 A binary FileDescriptorSet as produced by `protoc --include_imports --descriptor_set_out`.
 
-The schema record must be stored in the summary section of the trace file, and must be referenced by the OSI channels that use the schema.
+The schema record shall be stored in the summary section of the trace file, and shall be referenced by the OSI channels that use the schema.
 
 [#sec-osi-trace-file-multi-channel]
 === OSI channel
@@ -141,7 +141,7 @@ An OSI channel is a data stream within the OSI multi channel trace file that con
 Note that this specification does not allow the storage of non-top-level OSI messages in OSI channels, as they cannot be reliably associated with other OSI data streams without additional context (e.g. due to the absence of a timestamp field or lack of attribution).
 It is still possible to store them like any other related data in non-OSI channels, however this usage is unlikely to be portable.
 
-Each OSI channel must be described by a channel record in the summary section of the trace file with the following fields:
+Each OSI channel shall be described by a channel record in the summary section of the trace file with the following fields:
 
 `id`::
 A file-wide unique identifier for the channel.
@@ -177,11 +177,11 @@ The following recommended entries are defined by {THIS_STANDARD}:
 `net.asam.osi.trace.channel.description`:::
 A human-readable description of the channel.
 
-The channel record must be stored in the summary section of the trace file, and must be referenced by the OSI message records that are part of the channel.
+The channel record shall be stored in the summary section of the trace file, and shall be referenced by the OSI message records that are part of the channel.
 
-All messages in an OSI channel must be stored in chunk records in the data section of the trace file.
+All messages in an OSI channel shall be stored in chunk records in the data section of the trace file.
 
-Each message record in a chunk record must contain the following fields:
+Each message record in a chunk record shall contain the following fields:
 
 `channel_id`::
 The ID of the channel that the message belongs to.
@@ -200,7 +200,7 @@ Only if recreation of the message stream with actual message transmission times
 `publish_time`::
 The timestamp taken from the timestamp field of the stored OSI top-level message.
 The field is in nanoseconds, with the epoch being the epoch of the OSI Timestamp data type.
-If top-level messages that do not contain a timestamp field are stored in the trace file, the `publish_time` field must be set to the time when the message was enqueued for addition to the trace file.
+If top-level messages that do not contain a timestamp field are stored in the trace file, the `publish_time` field shall be set to the time when the message was enqueued for addition to the trace file.
 
 `data`::
 The serialized OSI message data.