Fix error logging ambiguity

docs/2_2_common_mechanisms.adoc

@@ -32,7 +32,7 @@ _Defensive implementations should still guard against `NULL` pointers.]_
 
 * The FMI Standard does not provide a runtime platform or portability layer.
 Access to operating system resources and services, such as memory, network or file system, should be implemented with special care because the availability of such resources and services is not guaranteed on every target platform and/or simulator.
-If some resource is required by the FMU but is not available, the FMU must log what resource failed and return with error.
+If some resource is required by the FMU but is not available, the FMU should log what resource failed (if <<loggingOn,`loggingOn = fmi3True`>>) and return with error.
 
 ==== Header Files and Naming of Functions [[header-files-and-naming-of-functions]]
 

docs/2_3_common_states.adoc

@@ -49,7 +49,7 @@ include::../headers/fmi3FunctionTypes.h[tags=Instantiate]
 +
 These functions return a new instance of an FMU with the respective interface type.
 If a NULL pointer is returned, then instantiation failed.
-In that case, the FMU must call <<logMessage>> with detailed information about the reason.
+In that case, the FMU may call <<logMessage>> with detailed information about the reason (if <<loggingOn,`loggingOn = fmi3True`>>).
 An FMU can be instantiated many times (provided capability flag `canBeInstantiatedOnlyOncePerProcess = false`).
 
 +
@@ -113,7 +113,7 @@ Pointer to a function that is called by the FMU to provide information about its
 
 ** `status` contains the severity of the message, see `fmi3Status`.
 If <<fmi3OK,`status = fmi3OK`>>, the message is a pure information message.
-If a function does not return <<fmi3OK>>, it must provide the reason by calling <<logMessage>> at least once with this `status`.
+If a function does not return <<fmi3OK>>, it may provide the reason by calling <<logMessage>> with this `status`, provided that <<loggingOn,`loggingOn = fmi3True`>>.
 ** `category` is the category of the message.
 The allowed values for `category` are defined in the <<modelDescription.xml>> file via the element <<definition-of-log-categories,`<LogCategories>`>>.
 <<logMessage>> must only be called for log categories that were enabled by calls to <<fmi3SetDebugLogging>> or via <<loggingOn,`loggingOn = fmi3True`>> in <<fmi3Instantiate>>.

docs/2_5_fmu_distribution.adoc

@@ -6,7 +6,7 @@ The FMU must be distributed with at least one implementation, in other words, ei
 It is also possible to provide the sources and binaries for different target machines together in one ZIP file.
 The FMU must implement all API functions declared in `fmi3Functions.h`, even if they are only needed for interface types or optional capabilities that the FMU does not support.
 The behavior of those functions is unspecified, so while calling environments can rely on the functions being present, they cannot rely on any particular behavior for functions only needed for capabilities or interface types the FMU does not support.
-_[The recommended implementation for such stub functions is to return `fmi3Error` after logging the error reason, as specified in <<status-returned-by-functions>>.
+_[The recommended implementation for such stub functions is to return `fmi3Error` and may log the error reason if <<loggingOn,`loggingOn = fmi3True`>>, as specified in <<status-returned-by-functions>>.
 Calling environments should not rely on the presence of functions that are not required and avoid calling them.]_
 Additional functions may be present in the FMU, as for example required by the OS ABI, for layered standards, or future FMI versions.
 All symbols starting with the prefix `fmi3` are reserved for use in future minor releases of FMI 3.0.