From 7a084843207d33768952e9995195b6a9f87ca677 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dag=20Br=C3=BCck?= Date: Fri, 2 Feb 2024 11:52:07 +0100 Subject: [PATCH 1/2] Clarification parameter designation Corresponds to issue #135. --- docs/5___ssd.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/5___ssd.adoc b/docs/5___ssd.adoc index db39ed4..81ff532 100644 --- a/docs/5___ssd.adoc +++ b/docs/5___ssd.adoc @@ -339,6 +339,8 @@ The hierarchical names of the parameters or other variables of a system are form {empty}[ _For example for a system A containing a system B which contains an exposed parameter named SP1 and an element C with a parameter P2, the hierarchical names of the parameters in system A are B.SP1 and B.C.P2 respectively. The hierarchical name of those parameters inside system B are SP1 and C.P2 respectively._ ] +{empty}[ _For example, a parameter binding of a e.g. a component A which contains an exposed parameter P shall reference the parameter using its local name P, not the hierarchical name A.P (possibly after any mapping)._ ] + Note that the hierarchical names of parameters or other variables do not have to be unique: If two or more variables end up with the same hierarchical name (due to so-called punning), then any parameter values being applied to that name *MUST* be applied to all of them. If this is not wanted, then it is up to the generating implementation to ensure that no punning occurs, through proper choice of system and element names. From 086ed70b3a2c39b5038e0def7fa294fcd882c163 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dag=20Br=C3=BCck?= Date: Thu, 14 Mar 2024 14:08:46 +0100 Subject: [PATCH 2/2] Update docs/5___ssd.adoc Co-authored-by: Pierre R. Mai --- docs/5___ssd.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/5___ssd.adoc b/docs/5___ssd.adoc index 81ff532..21f32bf 100644 --- a/docs/5___ssd.adoc +++ b/docs/5___ssd.adoc @@ -337,9 +337,9 @@ The hierarchical names of the parameters or other variables of a system are form * For all elements of the system, the hierarchical names of the variables of those elements are formed by prepending the element name and a dot to the hierarchical names of the variables in that element. {empty}[ _For example for a system A containing a system B which contains an exposed parameter named SP1 and an element C with a parameter P2, the hierarchical names of the parameters in system A are B.SP1 and B.C.P2 respectively. -The hierarchical name of those parameters inside system B are SP1 and C.P2 respectively._ ] +The hierarchical name of those parameters inside system B are SP1 and C.P2 respectively, and the hierarchical name of P2 inside element C is just P2. -{empty}[ _For example, a parameter binding of a e.g. a component A which contains an exposed parameter P shall reference the parameter using its local name P, not the hierarchical name A.P (possibly after any mapping)._ ] +Therefore a parameter binding on element C shall reference the parameter P2 using its local name P2, not the hierarchical name C.P2, which would be valid for a parameter binding on system B._ ] Note that the hierarchical names of parameters or other variables do not have to be unique: If two or more variables end up with the same hierarchical name (due to so-called punning), then any parameter values being applied to that name *MUST* be applied to all of them. If this is not wanted, then it is up to the generating implementation to ensure that no punning occurs, through proper choice of system and element names.