RE: [tag] Proposals for updating the "Anatomy of a TA" section (V0.6):

[david_marston@us.ibm.com]

My last missive inspired Jacques to respond:
>Indeed, if we want a TA to  do more than just repeat the specification
>requirement, it must include something about the nature of the test
>operation:
>E.g. 
>(An Error message is send out by MSH in response to receiving an
>ill-formed message 'M') AND (The ReferenceId field of the Error message
>has same value as the MessageId of M).
> 
>While "true"  clearly "indicates" conformance, "false" does not
>indicate
>non-conformance because the reason for failure may come from the first
>member of the boolean conjunction. Now, we may consider various ways to
>rewrite this, as one could argue that the above expression mixes two
>different things: (a) test preparation + (b) the actual test expression.
>For example, put the first member in a "test flow" part instead, or make
>it a pre-requisite, or both....

Right. And I thought it was noteworthy that the Unisoft/POSIX reference on 
Paul's prior-art list [1] defines the "condition" of an assertion as 
separate from the "cause" (like antecedent vs. trigger). They were 
thinking of condition as a qualifier up at the 
profile/module/level/deprecation range, but it may be applicable to the 
above example as well.

The above example also raises the question of whether there should be 
"variables" or a similar in TAs. In the above example...
When MSH receives an ill-formed message M
        let MID be the MessageID of M
        MSH must issue an error message E
                The referenceID of E must equal MID
If the above is a TA, it must be qualified as only having a meaningful 
outcome (pass/fail) if the MSH does in fact issue an error message. It may 
even be qualified by MSH issuing a specific message.
.................David Marston

[1] http://www.unisoft.com/glossary.html