[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion material for out-of-band components (agenda item 4.3.2)
The issue being addressed here is that normatively specifying an out-of-band action sometimes leads standards down a slippery slope that can result in expanding their scope each time something new comes up (which can happen over a period of months or years).
These options are not in any particular order except that this is how they came up in my discussion with Larry, so listing them this way means I don't have to renumber them.
Option 1: If a result object contains a baselineState property, then the containing run object SHALL contain a baselineInstanceGuid. Then there is no need for anything out of band. Option 2: If a result object contains a baselineState property and the containing run object is missing a baselineInstanceGuid, then the document could explicitly say that the method of determining the baseline run is unspecified, with a non-normative note indicating some methods that could be used to specify the baseline run. This avoids normatively specifying something that is out of band. Option 3: The engineering system SHALL provide out of band information (the status quo). Option 4: If a result object contains a baselineState property and the containing run object is missing a baselineInstanceGuid, then theengineering system SHALL provide documentation that explains how to determine the baseline run. This is a common approach in standards to avoid having the standard enlarge its scope, yet still have something the customer can use.