Discussion material for out-of-band components (agenda item 4.3.2)

[David Keaton <dmk@dmk.com>]

     I've been discussing the upcoming agenda item 4.3.2 (out-of-band 
components) with Larry off-line, and I have some options to offer that 
might help the teleconference discussion along.

     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 the
engineering 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.

					David