Fix xrefs to reverse-DNS (#2000)

docs/2_4_common_schema.adoc

@@ -1892,8 +1892,8 @@ The terminal name must be unique on each level.
 The normalized string attribute `matchingRule` describes the rules for variable matching in a connection of terminals.
 As detailed in <<table-predefined-matching-rules>>, there are four predefined matching rules: `plug`, `bus`, `sequence`, and `none`.
 Other standards may define new matching rules.
-In order to avoid ambiguities and conflicts, rule names must follow the <<reverse-dns,reverse domain name notation>> of a domain that is controlled by the entity defining the semantics and content of the additional entries.
-Such rule definitions can be part of a <<LS-reverse-DNS>>layered standard>>, for example.
+In order to avoid ambiguities and conflicts, rule names must follow the <<reverse-DNS,reverse domain name notation>> of a domain that is controlled by the entity defining the semantics and content of the additional entries.
+Such rule definitions can be part of a <<LS-reverse-DNS,layered standard>>, for example.
 
 .Predefined matching rules.
 [#table-predefined-matching-rules]
@@ -1927,7 +1927,7 @@ However, an importer may still connect terminals based on additional information
 [[terminalKind,`terminalKind`]]
 The normalized string `terminalKind` is an optional attribute.
 Other standards may define terminal kinds. 
-It is strongly recommended to use [[reverse-DNS, reverse domain name notation]] to define a `terminalKind`.
+It is strongly recommended to use <<reverse-DNS, reverse domain name notation>> to define a `terminalKind`.
 It is intended that the `terminalKind` is used to define domain specific member variable sequences, member names and order, or high level restrictions for connections.
 
 _[Externally defined terminal kinds should refer to a predefined `matchingRule`, if possible._
@@ -1963,7 +1963,7 @@ Therefore, the `memberName` attribute is required for `plug` and `bus` and must
 The `memberName` is not required for `matchingRule` `sequence`.
 
 The normalized string `variableKind` is used to provide general information about the variable.
-It is strongly recommended to use [[reverse-DNS, reverse domain name notation]] to define a `variableKind`.
+It is strongly recommended to use <<reverse-DNS, reverse domain name notation>> to define a `variableKind`.
 This information defines how the connection of this variable has to be implemented (e.g. Kirchhoff's current law or common signal flow).
 
 The predefined `variableKind` are:

docs/2_5_fmu_distribution.adoc

@@ -205,7 +205,7 @@ For more information, please consult the https://modelica.github.io/fmi-guides/m
 
 The ZIP archive may contain additional subdirectories within `extra/` that can be used to store additional data, e.g. for the implementation of <<VersioningLayered,layered standards>>.
 
-In order to avoid ambiguities and conflicts, the names of these subdirectories should use the <<reverse-dns,reverse domain name notation>> of a domain that is controlled by the entity defining the semantics and content of the additional entries _[(for example `extra/com.example/SimTool/meta.xml` or `extra/org.example.stdname/data.asd`)]_.
+In order to avoid ambiguities and conflicts, the names of these subdirectories should use the <<reverse-DNS,reverse domain name notation>> of a domain that is controlled by the entity defining the semantics and content of the additional entries _[(for example `extra/com.example/SimTool/meta.xml` or `extra/org.example.stdname/data.asd`)]_.
 It is explicitly allowed for tools and users other than the original creator of an FMU to modify, add or delete entries in the `extra/` directory without affecting the validity of the FMU in all other aspects.
 Specifically all validation or digital signature schemes used to protect the content of the FMU should take the variability of extra file content into account _[(for example by having separate checksums or signatures for FMU core content and extra content, or not having signatures at all for extra content)]_.
 

docs/2_6_versioning_layered_standards.adoc

@@ -75,7 +75,7 @@ An example schema that describes the simple example of a manifest above is shown
 include::examples/fmi_ls_manifest_example_schema.xsd[]
 ----
 
-[[LS-reverse-DNS]]Layered standards use the <<reverse-dns,reverse domain name notation>> of a domain under the control of the organizations that releases the layered standard to reserve namespaces.
+[[LS-reverse-DNS]]Layered standards use the <<reverse-DNS,reverse domain name notation>> of a domain under the control of the organizations that releases the layered standard to reserve namespaces.
 All namespaces under both the `org.modelica` and `org.fmi-standard` domains are reserved for use in future layered standards.
 
 _[For example, extensions defined by the Modelica Association might make use of the `org.modelica.fmi` namespace._

docs/7___appendix.adoc

@@ -178,8 +178,8 @@ The execution of a model partition is triggered by the activation of its Clock.
 Examples are a mass, stiffness, etc.
 These parameters are different from <<calculatedParameter,calculated parameters>>, because they can be changed independently (according to their <<variability>>).
 
-|[[reverse-DNS]]_revers domain name notation_
-A naming convention based on registered domain names, with the order of the components reversed for grouping purposes. 
+|[[reverse-DNS]]_reverse domain name notation_
+|A naming convention based on registered domain names, with the order of the components reversed for grouping purposes. 
 
 |[[reinitialization]]_reinitialization_
 |Recalculation of <<state,continuous-time states>> by the model.