Clean up formatting

- apply "one line per sentence" rule
- remove excess line breaks
- remove custom CSS indentations

docs/0___preamble.adoc

@@ -35,8 +35,7 @@ Please report issues that you find with this specification to the public FMI iss
 
 *License of this document*
 
-[role=second-indented]
-Copyright (C) +
+Copyright (C)::
 2008-2011 MODELISAR consortium and +
 2012-2014 Modelica Association Project "FMI"
 
@@ -67,19 +66,14 @@ The legal license text and disclaimer is available at:
 
 http://creativecommons.org/licenses/by-sa/4.0/legalcode
 
-Note:
-
-[role=indented2]
+Note::
 Article (3a) of this license requires that modifications of this work must clearly label, demarcate or otherwise identify that changes were made.
-
-[role=indented2]
++
 The C header and XML-schema files that accompany this document are available under the BSD 2-Clause license (http://www.opensource.org/licenses/bsd-license.html) with the extension that modifications must be also provided under the BSD 2-Clause license.
-
-[role=indented2]
++
 Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights.
 Modelica Association shall not be held responsible for identifying such patent rights.
-
-[role=indented2]
++
 If you have improvement suggestions, please send them to the FMI development group at mailto:[email protected].
 
 **Abstract**

docs/1___overview.adoc

@@ -104,7 +104,7 @@ For details, see chapters 3 and 4.
 [caption="Figure 1: "]
 image::images/enclosing_model.svg[width=60%, align="center"]
 
-Publications for FMI are available from https://fmi-standard.org/literature/, 
+Publications for FMI are available from https://fmi-standard.org/literature/,
 specially Blochwitz et.al. http://www.ep.liu.se/ecp/063/013/ecp11063013.pdf[2011] and http://www.ep.liu.se/ecp/076/017/ecp12076017.pdf[2012].
 
 
@@ -117,193 +117,118 @@ This shall increase self consistency of the interface functions.
 The listed issues are sorted,
 starting from high-level properties to low-level implementation issues.
 
-[role=indented]
-_Expressivity_:
+Expressivity::
 The FMI provides the necessary features that Modelica(R), Simulink(R) and SIMPACK(R) models
 footnote:[Modelica is a registered trademark of the Modelica Association, Simulink is
 a registered trademark of the MathWorks Inc., SIMPACK is a registered trademark of SIMPACK AG.]
 can transform to an FMU.
 
-[role=indented]
-_Stability_: The FMI is expected to be supported by many simulation tools world-wide.
-Implementing such
-support is a major investment for tool vendors.
-Stability and backwards compatibility of the FMI
-has therefore high priority.
-To support this, the FMI defines "capability flags" that will be used by
-future versions of the FMI to extend and improve the FMI in a backwards compatible way,
-whenever feasible.
-
-[role=indented]
-_Implementation_:
+Stability::
+The FMI is expected to be supported by many simulation tools world-wide.
+Implementing such support is a major investment for tool vendors.
+Stability and backwards compatibility of the FMI has therefore high priority.
+To support this, the FMI defines "capability flags" that will be used by future versions of the FMI to extend and improve the FMI in a backwards compatible way, whenever feasible.
+
+Implementation::
 FMUs can be written manually or can be generated automatically from a modeling environment.
 Existing manually coded models can be transformed manually to a model according to the FMI standard.
 
-[role=indented]
-_Processor independence_: It is possible to distribute an FMU without knowing the target processor.
-This
-allows an FMU to run on a PC,
-a Hardware-in-the-Loop simulation platform or as part of the controller software of an ECU,
-for example, as part of an AUTOSAR SWC.
-Keeping the FMU independent of the target processor increases the usability
-of the FMU and is even required by the AUTOSAR software component model.
-Implementation: Using a textual FMU (distribute the C
-source of the FMU).
-
-[role=indented]
-_Simulator independence_: It is possible to compile,
-link and distribute an FMU without knowing the target simulator.
-Reason: The standard would be much less attractive otherwise,
-unnecessarily restricting the later use of an FMU at compile time
-and forcing users to maintain simulator specific variants of an FMU.
+Processor independence::
+It is possible to distribute an FMU without knowing the target processor.
+This allows an FMU to run on a PC, a Hardware-in-the-Loop simulation platform or as part of the controller software of an ECU, for example, as part of an AUTOSAR SWC.
+Keeping the FMU independent of the target processor increases the usability of the FMU and is even required by the AUTOSAR software component model.
+Implementation: Using a textual FMU (distribute the C source of the FMU).
+
+Simulator independence::
+It is possible to compile, link and distribute an FMU without knowing the target simulator.
+Reason: The standard would be much less attractive otherwise, unnecessarily restricting the later use of an FMU at compile time and forcing users to maintain simulator specific variants of an FMU.
 Implementation: Using a binary FMU.
-When generating a binary FMU
-such as a Windows dynamic link library (.dll) or a Linux shared object library (.so),
-the target operating system and eventually the target processor must be known.
-However, no run-time libraries,
-source files or header files of the target simulator are needed to generate the binary FMU.
-As a result,
-the binary FMU can be executed by any simulator running on the target platform
-(provided the necessary licenses are available,
-if required from the model or from the used run-time libraries).
-
-[role=indented]
-_Small run-time overhead_:
-Communication between an FMU and a target simulator through the FMI does
-not introduce significant run-time overhead.
-This is achieved by a new caching technique
-(to avoid computing the same variables several times)
-and by exchanging vectors instead of scalar quantities.
-
-[role=indented]
-_Small footprint_: A compiled FMU (the executable) is small.
-Reason: An FMU may run on an ECU (Electronic Control Unit,
-for example, a micro-processor),
-and ECUs have strong memory limitations.
-This is achieved by storing signal attributes
-(names, units, etc.)
-and all other static information not needed for model evaluation in a separate text file
-(= Model Description File)
-that is not needed on the micro-processor where the executable might run.
-
-[role=indented]
-_Hide data structure_:
+When generating a binary FMU such as a Windows dynamic link library (.dll) or a Linux shared object library (.so), the target operating system and eventually the target processor must be known.
+However, no run-time libraries, source files or header files of the target simulator are needed to generate the binary FMU.
+As a result, the binary FMU can be executed by any simulator running on the target platform (provided the necessary licenses are available, if required from the model or from the used run-time libraries).
+
+Small run-time overhead::
+Communication between an FMU and a target simulator through the FMI does not introduce significant run-time overhead.
+This is achieved by a new caching technique (to avoid computing the same variables several times) and by exchanging vectors instead of scalar quantities.
+
+Small footprint::
+A compiled FMU (the executable) is small.
+Reason: An FMU may run on an ECU (Electronic Control Unit, for example, a micro-processor), and ECUs have strong memory limitations.
+This is achieved by storing signal attributes (names, units, etc.) and all other static information not needed for model evaluation in a separate text file (= Model Description File) that is not needed on the micro-processor where the executable might run.
+
+Hide data structure::
 The FMI for Model Exchange does not prescribe a data structure (a C struct) to represent a model.
-Reason: the FMI standard shall not unnecessarily restrict or prescribe a
-certain implementation of FMUs or simulators (whichever contains the model data)
-to ease implementation by different tool vendors.
+Reason: the FMI standard shall not unnecessarily restrict or prescribe a certain implementation of FMUs or simulators (whichever contains the model data) to ease implementation by different tool vendors.
 
-[role=indented]
-_Support many and nested FMUs_:
+Support many and nested FMUs::
 A simulator may run many FMUs in a single simulation run and/or multiple instances of one FMU.
-The inputs and outputs of these FMUs can be connected with
-direct feed-through.
+The inputs and outputs of these FMUs can be connected with direct feed-through.
 Moreover, an FMU may contain nested FMUs.
 
-[role=indented]
-_Numerical Robustness_:
-The FMI standard allows that problems which are numerically critical
-(for example, time and state events, multiple sample rates, stiff problems)
-can be treated in a robust way.
+Numerical Robustness::
+The FMI standard allows that problems which are numerically critical (for example, time and state events, multiple sample rates, stiff problems) can be treated in a robust way.
 
-[role=indented]
-_Hide cache_:
+Hide cache::
 A typical FMU will cache computed results for later reuse.
-To simplify usage and to reduce error possibilities by a simulator,
-the caching mechanism is hidden from the usage of the FMU.
+To simplify usage and to reduce error possibilities by a simulator, the caching mechanism is hidden from the usage of the FMU.
 Reason: First, the FMI should not force an FMU to implement a certain caching policy.
-Second,
-this helps to keep the FMI simple.
-
-[role=indented]
-_Implementation_:
-The FMI provides explicit methods
-(called by the FMU environment)
-for setting properties that invalidate cached data.
-An FMU that chooses to implement a cache may maintain a set of "dirty" flags,
-hidden from the simulator.
-A get method,
-for example to a state, will then either trigger a computation, or return cached data,
-depending on the value of these flags.
-
-[role=indented]
-_Support numerical solvers_:
+Second, this helps to keep the FMI simple.
+
+Implementation::
+The FMI provides explicit methods (called by the FMU environment) for setting properties that invalidate cached data.
+An FMU that chooses to implement a cache may maintain a set of "dirty" flags, hidden from the simulator.
+A get method, for example to a state, will then either trigger a computation, or return cached data, depending on the value of these flags.
+
+Support numerical solvers::
 A typical target simulator will use numerical solvers.
-These solvers require vectors for states,
-derivatives and zero-crossing functions.
+These solvers require vectors for states, derivatives and zero-crossing functions.
 The FMU directly fills the values of such vectors provided by the solvers.
 Reason: minimize execution time.
-The exposure of these vectors conflicts somewhat with the "hide data structure" requirement,
-but the efficiency gain justifies this.
+The exposure of these vectors conflicts somewhat with the "hide data structure" requirement, but the efficiency gain justifies this.
 
-[role=indented]
-_Explicit signature_:
+Explicit signature::
 The intended operations, argument types and return values are made explicit in the signature.
-For example, an operator (such as `compute_derivatives`) is not passed as an int
-argument but a special function is called for this.
-The `const` prefix is used for any pointer that should not be changed,
-including `const char*` instead of `char*`.
-Reason: the correct use of the FMI can be checked at compile time
-and allows calling of the C code in a C++ environment
-(which is much stricter on `const` than C is).
+For example, an operator (such as `compute_derivatives`) is not passed as an int argument but a special function is called for this.
+The `const` prefix is used for any pointer that should not be changed, including `const char*` instead of `char*`.
+Reason: the correct use of the FMI can be checked at compile time and allows calling of the C code in a C++ environment (which is much stricter on `const` than C is).
 This will help to develop FMUs that use the FMI in the intended way.
 
-[role=indented]
-_Few functions_:
-The FMI consists of a few,
-"orthogonal" functions,
-avoiding redundant functions that could be defined in terms of others.
-Reason: This leads to a compact, easy-to-use,
-and hence attractive API with a compact documentation.
+Few functions::
+The FMI consists of a few, "orthogonal" functions, avoiding redundant functions that could be defined in terms of others.
+Reason: This leads to a compact, easy-to-use, and hence attractive API with a compact documentation.
 
-[role=indented]
-_Error handling_:
+Error handling::
 All FMI methods use a common set of methods to communicate errors.
 
-[role=indented]
-_Allocator must free_:
+Allocator must free::
 All memory (and other resources) allocated by the FMU are freed (released) by the FMU.
 Likewise, resources allocated by the simulator are released by the simulator.
-Reason: this helps to prevent memory leaks and run-time errors due
-to incompatible run-time environments for different components.
+Reason: this helps to prevent memory leaks and run-time errors due to incompatible run-time environments for different components.
 
-[role=indented]
-_Immutable strings_:
-All strings passed as arguments or returned are read-only
-and must not be modified by the receiver.
+Immutable strings::
+All strings passed as arguments or returned are read-only and must not be modified by the receiver.
 Reason: This eases the reuse of strings.
 
-[role=indented]
-_Named list elements_:
-All lists defined in the `fmiModelDescription.xsd` XML schema file have a String
-attribute `name` to a list element.
-This attribute must be unique with respect to all other `name`
-attributes of the _same_ list.
+Named list elements::
+All lists defined in the `fmiModelDescription.xsd` XML schema file have a String attribute `name` to a list element.
+This attribute must be unique with respect to all other `name` attributes of the _same_ list.
 
-[role=indented]
-_Use C_:
+Use C:
 The FMI is encoded using C, not C++.
 Reason: Avoid problems with compiler and linker dependent behavior.
 Run FMU on embedded target.
 
-This version of the functional mock-up interface does
-[underline]#not# have the following desirable properties.
+This version of the functional mock-up interface does [underline]#not# have the following desirable properties.
 They might be added in a future version.
 
 - The FMI for Model Exchange is for ordinary differential equations (ODEs) in state space form.
 It is not for a general differential-algebraic equation system.
-However, algebraic equation systems inside the FMU are supported
-(for example, the FMU can report to the environment to re-run the current step
-with a smaller step size since a solution could not be found for an algebraic equation system).
+However, algebraic equation systems inside the FMU are supported (for example, the FMU can report to the environment to re-run the current step with a smaller step size since a solution could not be found for an algebraic equation system).
 
-- Special features that might be useful for multibody system programs,
-like SIMPACK, are not included.
+- Special features that might be useful for multibody system programs, like SIMPACK, are not included.
 
 - The interface is for simulation and for embedded systems.
-Properties that might be additionally
-needed for trajectory optimization,
-for example, derivatives of the model with respect to parameters
-during continuous integration are not included.
+Properties that might be additionally needed for trajectory optimization, for example, derivatives of the model with respect to parameters during continuous integration are not included.
 
 - No explicit definition of the variable hierarchy in the XML file.
 
@@ -322,5 +247,7 @@ LMS Imagine and IFPEN thank DGCIS for partial funding of this work within MODELI
 Since Sept. 2012 until Nov. 2015, this work is partially carried out within the ITEA2 MODRIO project (project number: ITEA 2-11004, https://itea3.org/project/modrio.html).
 
 - DLR, ITI GmbH, QTronic GmbH and SIMPACK AG thank BMBF for partial funding of this work within MODRIO (BMBF Förderkennzeichen: 01IS12022E).
+
 - Dassault Systèmes (Sweden), Linköping University and Modelon AB thank the Swedish funding agency VINNOVA (2012--01157) for partial funding of this work within MODRIO.
+
 - Siemens PLM Software (France) and IFPEN thank DGCIS for partial funding of this work within MODRIO.