[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: More about variables (and global predicates)
The notion of "properties" for issue 31 has some similarities with "variables" but also some differences. Properties seem to be related to discretionary (a.k.a. implementation-defined) items, which is a Dimension of Variability that specs can allow. A variable can contain the value of such a property, or it can contain a temporary value that is determined while a particular unit is being tested. (The previously provided fuse example is a case of the latter.) What the properties and variables have in common is that the value is not necessarily obtained by testing. It may be obtained by reading the vendor's documentation or asking the vendor to provide the data. This is interesting because it means that where the spec requires that there be a testable method of obtaining the value, failure of that method does not preclude further testing where the value is needed. Now, I'll present a new, more elaborate example of the use of variables, drawn from a real XPath/XQuery situation. The discretionary item in this case is the "default collation" to be used whenever collation is needed and not locally specified. There are about a dozen string functions that need collation, all of which take a collation URI as an *optional* argument. There are also other operators and instructions that need collation. Every conformant implementation must have a default, but the specific default chosen is up to the vendor's discretion. This default must be the same across all functions etc. that use collation, which motivates the variable. The default collation for a given implementation can be determined either from reading the vendor documentation or as the return of the default-collation() function. If that function fails, one must depend on the vendor statement. The function is required to return one string in all circumstances. If it returns the wrong string (lies about its default), the test suite could include enough tests to detect that fact. (There could be other examples where there is no way to check the accuracy of the function that reports a particular property.) Other test cases involving the optional collation argument do not need to depend on the proper functioning of default-collation() as long as there is a way to enter the correct default as a parameter to the test case. This would be facilitated by a variable in the test assertion. Collectively, all test cases that exercise collation but do not have the collation scheme set explicitly would be based on TAs that have a reference to the *same* variable. Determine the value once, and hundreds of test cases are ready to run. The notion of "global predicate" strikes me as a refinement of the terminology, but possibly more awkward for situations like the default collation, which cannot be reduced to a true/false dichotomy. At this time, there isn't any central registry of collation URIs, so any URI is an allowable collation URI. Please note that I was assuming composability wherever possible. If the property/variable represents the presence or absence of an optional module as a boolean value, then it can be used in boolean expressions along with predicates from TAs (i.e., measured properties). If the property/variable is numeric, as in the fuse rating example, then it can be used in numeric expressions. But where the property/variable is an arbitrary string, as is the default collation (for now, at least), there should be a way to obtain the benefits of its globality, even though it can't be reduced to a predicate. So global predicates and variables may be two separate concepts. But please discuss whether all could be subsumed under global variables, with predicates (or boolean variables) being a special case that has more ways to be used. .................David Marston
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]