OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tag-comment message

[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 
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, 
test cases that exercise collation but do not have the collation scheme 
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 

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 
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]