Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarification for matching #1808

Merged
merged 11 commits into from
Oct 12, 2022
Merged

Clarification for matching #1808

Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
31a26c0
First draft of clarification for matching
chrbertsch Sep 7, 2022
5869447
Fix some spelling issues
andreas-junghanns Sep 7, 2022
36334a4
make requirements normative
chrbertsch Sep 8, 2022
550d76d
Merge branch 'fix-match' of https://github.com/chrbertsch/fmi-standar…
chrbertsch Sep 8, 2022
09dc4de
change to comment
chrbertsch Sep 8, 2022
9e99637
spelling issue
CSchulzeTLK Sep 8, 2022
9b7f592
spelling issue
CSchulzeTLK Sep 8, 2022
805b95e
add variableNamingConvention link
chrbertsch Sep 9, 2022
55415ed
Changes according to Christian S's suggestions
chrbertsch Sep 13, 2022
c465dbc
Apply suggestions from code review
pmai Sep 28, 2022
8904eac
Fix formatting of non-normative text
andreas-junghanns Sep 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 10 additions & 2 deletions docs/2_4_common_schema.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ _If more space is required, the folder <<license-information,`licenses`>> should
|Optional date and time when the XML file was generated.
The format is a subset of `dateTime` and should be: `YYYY-MM-DDThh:mm:ssZ` (with one `T` between date and time; `Z` characterizes the Zulu time zone, in other words, Greenwich meantime) _[for example `2009-12-08T14:33:22Z`, according to ISO 8601]_.

|[[variableNamingConvention,`variableNamingConvention`]]<<variableNamingConvention>>
|[[variableNamingConvention,`Convention`]]<<variableNamingConvention>>
|Defines whether the variable names in <<ModelVariables>> and in `<TypeDefinitions>` follow the `flat` or `structured` convention as defined in <<namingSection>>.

|====
Expand Down Expand Up @@ -1927,7 +1927,15 @@ _Examples for `terminalKind`: `StandardXXX_Mechanical_Translational`, `Modelica.

_The structured naming convention of the <<ModelVariables>> is independent from the terminal names and member variable names._

_A tool may choose to connect terminals with a different or unknown `terminalKind`, if the `matchingRule` matches.]_
_A tool may choose to connect terminals with a different or unknown `terminalKind`, if the `matchingRule` matches._

_A tool may choose to take the structured naming convention of variable names into account when matching terminals._
_This can for example be used to allow matching between terminals employing arrays mapped to scalar variables using structured naming convention ("naming convention arrays"), and those using native FMI 3.0 arrays, as in the following example:_

pmai marked this conversation as resolved.
Show resolved Hide resolved
_Assume that an (FMI 3.0) FMU has a one-dimensional array variable `x` of length 3 as member variable of a terminal and is connected to another (FMI 2.0 or FMI 3.0) FMU supporting structured naming convention, which has scalar variables `x[1]`, `x[2]`, `x[3]` as member variables of a terminal._
_Then `x[1]`, `x[2]`, `x[3]` are interpreted as a "naming convention array" with name `x`, which "matches" the array variable `x` of the first FMU, in name-based matching._
_Similarly the notional "naming convention array" `x` would participate in sequence-based matching as a single notional variable in the place of the underlying scalar variables._
_]_

[[section-terminalvars]]
====== Terminal Member Variable
Expand Down