Terminals

docs/2_4_common_schema.adoc

@@ -1894,6 +1894,12 @@ Predefined rules for variable matching in a connection are given in <<table-pred
 Predefined variable kinds are used to describe how the terminal member variables have to be handled.
 Domain specific connection rules, terminals and their member variables can be provided by other standards, including layered standards.
 
+_[Terminal definitions provide heuristics to help importers connect FMUs and check compatibility.
+The matching rules and terminal kinds serve as guidance and should not be interpreted as strict requirements that prevent reasonable connections.
+Importers have flexibility in how they interpret and apply terminal information, and may choose to allow connections that are not explicitly covered by the rules defined here.
+This flexibility is intentional, as terminals are designed to work best within specific user communities or tool ecosystems where additional conventions and constraints may apply.
+Specific domains may provide more precise connection rules and semantics for their use cases.]_
+
 _[Algebraic loops in systems of connected FMUs are not addressed or resolved by the terminals._
 _The FMU standard does not require that the <<causality>> of the terminal member variables in connected terminals match._
 _This must be handled by the importer._
@@ -1949,6 +1955,17 @@ However, an importer may still connect terminals based on additional information
 
 |====
 
+_[When connecting two terminals, each terminal's `matchingRule` is evaluated independently for that terminal.
+For example, a terminal with `matchingRule="plug"` can be connected to a terminal with `matchingRule="bus"` as long as the requirements of each rule are satisfied from that terminal's perspective:
+The plug terminal requires all its member variables to be present in the connection, while the bus terminal allows for partial matching.
+This asymmetric matching is intentional and supports flexible connection scenarios._
+
+_For hierarchical (nested) terminals, matching is performed at each level according to the `matchingRule` of that level.
+Each terminal and sub-terminal is matched according to its own `matchingRule`, and the specific order of traversal or flattening is left to the importer's discretion._
+
+_A single variable from <<ModelVariables>> may be referenced by multiple terminals within the same FMU.
+This allows the same variable to participate in different connection contexts or to be grouped in multiple logical interfaces.]_
+
 [[terminalKind,`terminalKind`]]
 The normalized string `terminalKind` is an optional attribute.
 Other standards may define terminal kinds.