From ff6aff09dd501a62f32520ff6248eebadfc716ce Mon Sep 17 00:00:00 2001 From: Nikolai Fast Date: Thu, 7 Nov 2024 09:51:32 +0100 Subject: [PATCH] Fix xrefs to reverse-DNS (#2000) --- docs/2_4_common_schema.adoc | 8 ++++---- docs/2_5_fmu_distribution.adoc | 2 +- docs/2_6_versioning_layered_standards.adoc | 2 +- docs/7___appendix.adoc | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/2_4_common_schema.adoc b/docs/2_4_common_schema.adoc index 88eb807db..3043b1760 100644 --- a/docs/2_4_common_schema.adoc +++ b/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 <>, 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 <> 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 <>layered standard>>, for example. +In order to avoid ambiguities and conflicts, rule names must follow the <> 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 <>, 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 <> 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 <> 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: diff --git a/docs/2_5_fmu_distribution.adoc b/docs/2_5_fmu_distribution.adoc index 0ce49b950..0d1c992a7 100644 --- a/docs/2_5_fmu_distribution.adoc +++ b/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 <>. -In order to avoid ambiguities and conflicts, the names of these subdirectories should use the <> 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 <> 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)]_. diff --git a/docs/2_6_versioning_layered_standards.adoc b/docs/2_6_versioning_layered_standards.adoc index 6ab5fc29d..ea531cf1f 100644 --- a/docs/2_6_versioning_layered_standards.adoc +++ b/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 <> of a domain under the control of the organizations that releases the layered standard to reserve namespaces. +[[LS-reverse-DNS]]Layered standards use the <> 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._ diff --git a/docs/7___appendix.adoc b/docs/7___appendix.adoc index a6d9ae2fd..bcbde7873 100644 --- a/docs/7___appendix.adoc +++ b/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 <>, because they can be changed independently (according to their <>). -|[[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 <> by the model.