Comments on TAG 0.7

[david_marston@us.ibm.com]

1. Observation #4 in part 2.2 should be broken into two. The first 
sentence is fine where it is. All the rest, about p IMPLIES q being "the 
same" as q OR NOT p should be deferred until near the end of part 2.3, 
after the role of (condition) has been put into the perspective of 
prerequisites. The operators may be equivalent from a logician's 
viewpoint, but the IMPLIES operator has a suggestion of asymmetry which is 
correct and desirable in this application.

2. In part 3.2, the example for variables is quite weak. A better one that 
is easy to understand involves fuses. First, here is a TA that might be 
used in a dependency relationship:
TA ID: Fuse-1
Target: any fuse
Predicate: the rating of the fuse, in amps, is clearly shown on its 
exterior.
(Statement in spec: Every conforming fuse MUST have its rating, in amps, 
clearly shown on the exterior.)

The above gives the test lab a means to determine the value of the 
variable used in this assertion:
TA ID: Fuse-2
Prereq: Fuse-1
Variable: X, the rating, in amps, of the fuse
Target: any fuse
Predicate: for a fuse of rating X, it will blow when given a load of 
1.025X amps.

Clearly, the standards body for fuses (NFPA, I think) is not going to 
issue a TA specific to each and every possible rating.

3. There is a placeholder for "Identifying Versions" in 3.2. I think the 
first paragraph should point out that while a spec document is produced 
anew for each version, that does not require that a set of TAs be produced 
anew. The TAs can cross several spec versions as long as they have the 
proper version data.

Back when I was working on the OASIS TC on XSLT conformance testing, we 
devised two separate values:
VersionAdd: the lowest numerical version to which the test applies. 
(Absence of this value implies the default of 1.0)
VersionDrop: if present, it is a number higher than VersionAdd (or 1.0) 
and indicates the lowest version number to which the test does NOT apply. 
Numbering it this way allows a version like 2.3 to be issued after 3.0 
without disturbing cases that no longer apply as of 3.0. If we had instead 
used the highest-number version to which it does apply, in this example we 
might have given the value 2.2 to those cases that would not apply to 3.0, 
but the cases may well have applied to 2.3, when 2.3 was issued.

I think this VersionAdd/VersionDrop scheme can be applied to TAs.
.................David Marston