Trying to get at the essence of variables

[david_marston@us.ibm.com]

Here is a set of changes that would make the treatment of variables 
appropriately simple, as I believe you want it to be for the first edition 
of the document. I looked at the Appendix C example, and I am wavering 
about whether it should be simplified to match.
.................David Marston
IBM Research

Glossary entry:
Variable
Employed by the writer of a TA to refer to a value that is not known at 
the time the TA is written, but will be determined at some later stage, 
possibly as late as the middle of running a set of tests. It is also 
employed to enable several assertions to share a value (set once, used by 
many), like a variable in other technologies.

Section 3.8:
3.8 Variables and Target Properties
Variables have a similar role in test assertions as in other technologies. 
They provide a means for consistently sharing values across multiple 
assertions and with other processes. The writer of a set of TAs can use a 
variable to assert that all occurrences of that variable must have the 
same value, even if that value cannot be known at the time the TAs are 
written. For example, consider a set of assertions all sharing a reference 
to the line (mains) voltage supplied by the local electric utility, where 
the specific locality will vary. By declaring a variable for this value 
and distinguishing the name by, for example, representing it in upper case 
(UTILITY-VOLTAGE), each test assertion can use it within its elements and 
expressions. (Some people prefer the term "parameter" and would say that 
the test assertions in question are "parameterized.")
The following example also shows the use of the variable within the 
predicate. Here, specification requirement 104 depends on the utility 
voltage.
Variable: 'UTILITY-VOLTAGE' the voltage commonly provided for hand-held 
electrical appliances and laptop computers. 
TA id: widget-TA100-6a

Target: widget

Normative Source: specification requirement 104

Predicate: [the widget] can operate when supplied UTILITY-VOLTAGE via its 
power cord.

Prescription Level: mandatory

A value would then be assigned to 'UTILITY-VOLTAGE' prior to testing.
A more realistic extension of the above example is to have one variable 
for the.geo-political locality of an implementation, along with a 
collection of dependent variables for voltage, line frequency, language, 
roadway dimensions, and all other values that vary by physical location. 
The mapping from the externally-derived variable (LOCALE) to the other 
variables can be through bundles of logic statements, lookup tables, or 
other means. That way, the widget that has some values from one country 
and some from a different country, and is therefore not usable in any 
country, is detected by testing.
Variables can be used in prerequisites (see section 3.3) and other parts 
of a TA. A variable may be used in one element in one TA and in a 
different element in another TA in the same collection. For example, the 
widget-TA100-6a assertion above might be in a collection along with a TA 
whose prerequisite restricts it to locations where LINE-VOLTAGE exceeds 
250.
In some cases, the variable has a value known or assigned during test 
assertion authoring, and is simply used to allow agile resetting of its 
value. In other cases, the variable can be declared in name only, leaving 
the value to be assigned at a subsequent stage, such as in an 
implementation itself or in a conformance clause for a profile, level or 
module. The value might be measured during testing and could be associated 
with a property (see section 3.2). For example, if the medium-size 
property is true for a widget, the SIZE variable is set to the value 
"medium".
Variables can be used across elements in a single TA.
A particular consideration in using variables is variable scope. For 
example, a grouping construct might be a place to declare variables whose 
scope only applies to those test assertions associated with that grouping. 
This allows the same variable and its value to be used across several test 
assertions while avoiding problems with name clashes in test assertions 
outside of the variable's scope.