Open adammontville opened 4 years ago
That is a good summary of the problem at hand. For the proposal, I would recommend the following:
1) Use a notation such as GM1, GM2, etc. and GI1, GI2, etc. to represent global measures and global inputs.
2) Local measures and local inputs would just be represented with M1, M2, etc. and I1, I2, etc.
3) The local measures and inputs would be numbered independently by Sub-Control rather than continuously across Sub-Controls.
4) If a change results in a missing entry for a measure or for an input, that is fine. I do not think we should renumber the remaining measures or inputs. For instance, if a Sub-Control has measures M1 through M4 and we convert M1 into a global measure (let's say GM6), then the resulting list of measures would be GM6, M2, M3, and M4. Later, if we decide that M3 is unnecessary, the list would be GM6, M2, and M4.
The rationale for these suggestions: 1) Numbering continuously across Sub-Controls would mean that changes to earlier Sub-Controls would ripple through all the later Sub-Controls causing a great deal of renumbering (for example if we added or removed a measure from Sub-Control 2.2). Or, future versions where we added a measure might have numbering like M1, M2, M878. 2) Keeping the existing M1, M2, etc. for non-global measures would result in fewer changes. This is both a time-saving measure, and to reduce errors. Changing the name of a measure results in many manual changes since measures are often referenced by operations, other measures, metrics, etc. Changing all of these references manually will be an error prone process and should be kept to a minimum; only those changes that really add value should be undertaken. 3) The time-saving and minimizing changes argument in 2) also applies to not updating the numbering due to missing measures and inputs (if we remove some or make a measure a global measure for instance).
Ideally we would have a document writing system that uses variables so one change would also change all the references, but currently, I'm not sure which system that would be.
Good comments @apiperCIS, and I tend to agree with that approach. Then:
GIx
, where x
is a positive integer incrementing from 1
across all sub-controls - we will call these global inputsGMx
, where x
is a positive integer incrementing from 1
across all sub-controls - we will call these local inputsIx
, where x
is a positive integer within a given sub-control - we will call these local inputsMx
, where x
is a positive integer within a given sub-control - we will call these local measuresSCx.y
or x.y
, where x.y
identifies the sub-control (i.e. SC3.1
or 3.1
).
) or dash (-
), and the local input or local measure (i.e. SC3.1.M1
or 3.1-M1
)2nd bullet should call them "Global Measures", not "local inputs"
Thanks, @wmunyan, you're correct. Fixed here:
GIx
, where x
is a positive integer incrementing from 1
across all sub-controls - we will call these global inputsGMx
, where x
is a positive integer incrementing from 1
across all sub-controls - we will call these global measuresIx
, where x
is a positive integer within a given sub-control - we will call these local inputsMx
, where x
is a positive integer within a given sub-control - we will call these local measuresSCx.y
or x.y
, where x.y
identifies the sub-control (i.e. SC3.1
or 3.1
).
) or dash (-
), and the local input or local measure (i.e. SC3.1.M1
or 3.1-M1
)I would suggest dropping the dash within the concatenation specification and just leave the designator with the dot as a field separator. If you are coding a system then it is easier just to look for a single character field separator within a function rather than having to look for multiple characters.
@Tonyknz, good suggestion, thank you.
Problem
In the specification, each Sub-Control contains a set of Inputs and a set of Measures. Inputs are presented as ordered lists, so that the specification can reference them as "Input
x
". Measures are denoted asMx
, wherex
is a positive integer. Input and measure labels are effectively reset for each Sub-Control. For example, the input ordered list at the beginning of each Sub-Control resets to begin numbering at1
, andM1
exists across all Sub-Controls. In the case of the measures, more often than not similarly labeled measures carry different meaning.From time to time, the same inputs and measures may be used across Sub-Controls. For example:
M3 = Count of endpoints (from Input 1)
, where Input 1 is the "List of endpoints"M7 = Count of endpoints from Input 1
, where Input 1 is the "Endpoint Inventory"In the above example, the inputs for Sub-Controls 3.1 and 4.8 are synonymous, but clearly not expressed using the same language. While "list of endpoints" is intended to be equivalent to "endpoint inventory", the specification needs to use the same language.
It then follows that
M3
of Sub-Control 3.1 andM7
of Sub-Control 4.8 are clearly the same measure.The fact that same inputs and same measures are referenced differently across Sub-Controls makes implementation more challenging.
Proposal
The specification may benefit from standardizing inputs and measures across Sub-Controls using variables.
Input variables may be denoted by
Ix
, wherex
is a positive integer starting with1
for the first input of the first Sub-Control, and will be incremented by one for each new input across Sub-Controls.Measure variables may be denoted by
Mx
wherex
is a positive integer starting with1
for the first measure of the first Sub-Control, and will be incremented by one for each new measure across Sub-Controls.