RE: [tag-comment] Re: [tag] First TA guideline draft is out

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Thx David  for this feedback.
Your point below is well taken and calls indeed for a Best Practice
note, that predicates of the form "if...then..." may produce misleading
outcomes for a TA and ultimately, conformance evaluation. the
"conditional"  part should be part of the prerequisite so that
inapplicability can be detected.

Jacques


>...by way of NOT(condition) being true. Unscrupulous widget
manufacturers would say things like "We pass 97% of the conformance
tests" and use TAs like this to bulk up their pass percentage. I would
hope that the document as a whole (not necessarily 4.1) includes some
Best Practice for authoring TAs using prerequisites (or preconditions?)
or "target classifications" so that inapplicable TAs can be easily
segregated from ones where the pass/fail outcome is meaningful. Then 4.1
could make a note about that Best Practice. (BTW, passing rates other
than 100% are invalid and specs should have a disclaimer to that
effect.)

-----Original Message-----
From: david_marston@us.ibm.com [mailto:david_marston@us.ibm.com] 
Sent: Wednesday, January 23, 2008 8:42 AM
To: tag-comment@lists.oasis-open.org
Subject: [tag-comment] Re: [tag] First TA guideline draft is out

Some general notes for your consideration:

Part 3.1: The notion each TA is an "independent" statement still
requires some kind of elaboration. As written, the TA may have
contingencies, have an implicit target or predicate, or be part of a
group, so it's more like the written TA can be resolved into a pure TA
that might have a long list of contingencies. Some of those
contingencies may be expressed as other TAs, giving the appearance of
non-independence. Sequencing is another challenge to this notion.

Part 3.3: this looks non-normative to me. I don't object to it being 

there, but maybe Appendix B was designed for this sort of material.

Part 4.1: TA target should be harmonized with the Class of Product from
QA
Framework: Spec Guidelines.

Today, Jacques sent a note that includes the observation:
JD>...a test assertion predicate may also be of the kind: ?if 
JD>(condition)
then (expression) ? which is just another way to represent the Boolean
expression: (expression) OR NOT(condition)...
This reinforces my continuing discomfort with accounting for variability
as part of the condition. Using the 4.1 example, a large widget "passes"

the TA
>if [the widget] is medium-size, then [the widget] uses exactly one AA
battery
by way of NOT(condition) being true. Unscrupulous widget manufacturers
would say things like "We pass 97% of the conformance tests" and use TAs
like this to bulk up their pass percentage. I would hope that the
document as a whole (not necessarily 4.1) includes some Best Practice
for authoring TAs using prerequisites (or preconditions?) or "target
classifications" so that inapplicable TAs can be easily segregated from
ones where the pass/fail outcome is meaningful. Then 4.1 could make a
note about that Best Practice. (BTW, passing rates other than 100% are
invalid and specs should have a disclaimer to that effect.)

Part 4.2: The notion of sequencing is introduced. Eventually, you have
to explain how this resolves against the notion that each TA is
independent. 
5.5 makes a first effort.

Observation #5 is one of the best bits of verbiage to come from this TC
so far! Properties obtained from this type of TA may need to be
"variables" 
(see my message of 12/6/2007) if they are not properties given formal
criteria by the spec.

Part 4.3: optional items (SHOULD statements) are related to the
Dimensions of Variability (DoV), but not in a simple way. They could be
Discretionary Items, but sometimes the SHOULD statement is not
feature-centric. The paragraph about DoV will probably need more
wordsmithing to make this clear. When the optional part rises to the
level of a Module, it is a different kind of DoV. The product MAY have
the module, but if it does, a group of MUST statements apply to the
module. Typically, a product NOT having the module MUST exhibit some
other behaviors relating to the absence of the module.

Parts 5.1, 5.3, and 5.4: I'm looking forward to a specification of
"tags" 
as part of the anatomy. Clearly, one TA may need several tags. Do tags
need attributes and classification? I think they don't "need" it, but an
XML representation might want an optional tag-type attribute that has
several keyword values, including a keyword for each DoV.

Part 5.7: Will this be the pre-req discussion, or will it be in 4.2.1?

Appendix A: Thanks for the acknowledgement. Please spell my name right. 
Please expand my affiliation to "IBM Research".