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: 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 (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".


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]