Add links to literature

NikolaiFa · NikolaiFa · commit 064bc1f58a17 · 2025-10-20T13:58:02.000+02:00
diff --git a/docs/0___preamble.adoc b/docs/0___preamble.adoc
@@ -80,5 +80,5 @@ The standard is comprised of a set of XML-based formats to describe a network of
 
 *Conventions used in this Document*
 
-* The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* in this document are to be interpreted as described in RFC 2119 [RFC2119].
+* The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*, *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL* in this document are to be interpreted as described in RFC 2119 [<<RFC2119>>].
 * Non-normative text is given in square brackets in italic font: [ _especially examples are defined in this style._ ].
diff --git a/docs/1___overview.adoc b/docs/1___overview.adoc
@@ -4,7 +4,7 @@ SSP is a tool-independent format for the description, packaging and exchange of
 The standard is comprised of a set of XML-based formats to describe a network of component models with their signal flow and parameterization, as well as a ZIP-based packaging format for efficient distribution of entire systems, including any referenced models and other resources.
 This description is tool neutral and is intended to be used primarily as an exchange format of simulation system descriptions between different tools.
 
-SSP can be seen as an extension to the FMI (Functional Mockup Interface) standard [FMI30].
+SSP can be seen as an extension to the FMI (Functional Mockup Interface) standard [<<FMI30>>].
 FMI describes a tool independent standard to exchange single simulation models.
 Using SSP, complete systems consisting of multiple interconnected simulation models can be defined with the desired signal flow and also with the wanted parameterization of each single model as well as the parameters for the complete system.
 This system topology can include hierarchies of sub-systems for proper structuring of the overall system.
diff --git a/docs/2___common_concepts.adoc b/docs/2___common_concepts.adoc
@@ -39,7 +39,7 @@ In this fashion extension of SSP to support pre-existing, new or domain-specific
 
 === Versioning and Layered Standards
 
-The SSP standard uses semantic version numbers, as defined in [SV200], where the standard version consists of a triple of version numbers, consisting of major version, minor version, and patch version numbers [ _e.g. 1.2.3 for major version 1, minor version 2 and patch version 3_ ].
+The SSP standard uses semantic version numbers, as defined in [<<SV200>>], where the standard version consists of a triple of version numbers, consisting of major version, minor version, and patch version numbers [ _e.g. 1.2.3 for major version 1, minor version 2 and patch version 3_ ].
 
 * Major versions will introduce changes that are neither backward nor forward-compatible, including changes to the XML schemas to include new non-ignorable content.
 * Minor versions will only contain clarifications and include new layered standards, which may add new ignorable XML content, as defined below, into the core standard document, indicating that the standard needs to be supported by all conforming implementations.
diff --git a/docs/3___packaging.adoc b/docs/3___packaging.adoc
@@ -2,7 +2,7 @@
 
 System Structure Package (file extension .ssp) files are specified to allow the packaging of System Structure Description (`*.ssd`) files together with related resources, like referenced FMUs, parameter files, etc.
 
-System Structure Package files *MUST* be valid ZIP archives as specified in [ZIP635] with the following restrictions:
+System Structure Package files *MUST* be valid ZIP archives as specified in [<<ZIP635>>] with the following restrictions:
 
 * All file entries *MUST* use either compression method 0 (stored) or 8 (deflated).
 * Encryption *MUST NOT* be used.
diff --git a/docs/4___common_content.adoc b/docs/4___common_content.adoc
@@ -136,7 +136,7 @@ The following XML child elements are specified for the Unit element:
 ===== BaseUnit
 
 This element defines the base unit of the given unit in SI units.
-This is completely aligned with the specification of base units in section 2.4.3 of the FMI 3.0 standard [FMI30] and section 2.2.2 of the FMI 2.0 standard [FMI20].
+This is completely aligned with the specification of base units in section 2.4.3 of the FMI 3.0 standard [<<FMI30>>] and section 2.2.2 of the FMI 2.0 standard [<<FMI20>>].
 
 image:images/image10.png[image,width=263,height=771]
 
@@ -325,7 +325,7 @@ The name *MUST* match the name of an Enumeration entry in the Enumerations XML e
 
 image:images/image17.png[image,width=319,height=114]
 
-This type specifies that the connector in question represents a length-terminated binary data type, like the binary type defined for the FMI 3.0 standard, or substitute types like the binary type defined via the OSI Sensor Model Packaging specification [OSMP150].
+This type specifies that the connector in question represents a length-terminated binary data type, like the binary type defined for the FMI 3.0 standard, or substitute types like the binary type defined via the OSI Sensor Model Packaging specification [<<OSMP150>>].
 
 [width="100%",cols="28%,72%",options="header",]
 |===
diff --git a/docs/5___ssd.adoc b/docs/5___ssd.adoc
@@ -2,7 +2,7 @@
 
 A System Structure Description describes a nested hierarchy of interconnected (sub-)systems and atomic components.
 
-A System Structure Description file (SSD, file extension .ssd) *MUST* be a well-formed XML 1.0 [XML10] file that conforms to the SystemStructureDescription XML Schema distributed as part of this standard.
+A System Structure Description file (SSD, file extension .ssd) *MUST* be a well-formed XML 1.0 [<<XML10>>] file that conforms to the SystemStructureDescription XML Schema distributed as part of this standard.
 The file *MUST* use the UTF-8 encoding.
 All SSD-specific elements live in the `http://ssp-standard.org/SSP1/SystemStructureDescription` namespace, nicknamed `ssd`.
 
diff --git a/docs/6___ssv.adoc b/docs/6___ssv.adoc
@@ -5,7 +5,7 @@ The XML element can be inlined with its parent element or referenced from the pa
 
 For information on hierarchical naming structure and precedence rules, see <<ParameterBindings>>.
 
-An SSV file *MUST* be a well-formed XML 1.0 [XML10] file that conforms to the SystemStructureParameterValues XML Schema that is distributed as part of this standard.
+An SSV file *MUST* be a well-formed XML 1.0 [<<XML10>>] file that conforms to the SystemStructureParameterValues XML Schema that is distributed as part of this standard.
 The file *MUST* use the UTF-8 encoding.
 All SSV-specific elements live in the `http://ssp-standard.org/SSP1/SystemStructureParameterValues` namespace, nicknamed `ssv`.
 
diff --git a/docs/7___ssm.adoc b/docs/7___ssm.adoc
@@ -6,7 +6,7 @@ It can also optionally provide for transformations that are to be applied on the
 
 A parameter mapping can be provided either as a stand-alone XML file (an SSM file), which can be referenced from SSD files, or it can be embedded in an ssd:ParameterMapping element of the SSD directly (see <<ParameterMapping>>).
 
-An SSM file *MUST* be a well-formed XML 1.0 [XML10] file that conforms to the SystemStructureParameterMapping XML Schema that is distributed as part of this standard.
+An SSM file *MUST* be a well-formed XML 1.0 [<<XML10>>] file that conforms to the SystemStructureParameterMapping XML Schema that is distributed as part of this standard.
 The file *MUST* use the UTF-8 encoding.
 All SSM-specific elements live in the `http://ssp-standard.org/SSP1/SystemStructureParameterMapping` namespace, nicknamed `ssm`.
 
diff --git a/docs/8___ssb.adoc b/docs/8___ssb.adoc
@@ -4,7 +4,7 @@ A signal dictionary is a collection of signals defined through its DictionaryEnt
 
 A signal dictionary can be provided either as a stand-alone XML file (an SSB file), which can be referenced from SSD files, or it can be embedded in an ssd:SignalDictionary element of the SSD directly (see <<SignalDictionaries>>).
 
-An SSB file *MUST* be a well-formed XML 1.0 [XML10] file that conforms to the SystemStructureSignalDictionary XML Schema that is distributed as part of this standard.
+An SSB file *MUST* be a well-formed XML 1.0 [<<XML10>>] file that conforms to the SystemStructureSignalDictionary XML Schema that is distributed as part of this standard.
 The file *MUST* use the UTF-8 encoding.
 All SSB-specific elements live in the `http://ssp-standard.org/SSP1/SystemStructureSignalDictionary` namespace, nicknamed `ssb`.
 
diff --git a/docs/A___literature.adoc b/docs/A___literature.adoc
@@ -12,11 +12,11 @@ https://semver.org/spec/v2.0.0.html
 [XML10] World Wide Web Consortium: *Extensible Markup Language (XML) 1.0 (Fifth Edition).* W3C Recommendation. 2008. +
 http://www.w3.org/TR/2008/REC-xml-20081126/
 
-[FMI20] Modelica Association: *Functional Mock-up Interface for Model Exchange and Co-Simulation, Version 2.0.4.* 2022. +
-https://github.com/modelica/fmi-standard/releases/download/v2.0.4/FMI-Specification-2.0.4.pdf
+[FMI20] Modelica Association: *Functional Mock-up Interface for Model Exchange and Co-Simulation, Version 2.0.5.* 2024. +
+https://github.com/modelica/fmi-standard/releases/download/v2.0.5/FMI-Specification-2.0.5.pdf
 
-[FMI30] Modelica Association: *Functional Mock-up Interface Specification, Version 3.0.1.* 2023. +
-https://fmi-standard.org/docs/3.0.1/
+[FMI30] Modelica Association: *Functional Mock-up Interface Specification, Version 3.0.2.* 2024. +
+https://fmi-standard.org/docs/3.0.2/
 
 [OSMP150] ASAM e.V.: *OSI Sensor Model Packaging Version 1.5.0.* 2024. +
 https://github.com/OpenSimulationInterface/osi-sensor-model-packaging/releases/tag/v1.5.0
