comments on the TA model

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

 

Here is some late (sorry..) comments on the TA model: only minor things.

 

Nothing I see that would justify waiting any longer for a CD vote and PR.

 

However, if we have time to go through (dome of) these in the meeting, resolution is obvious and

could easily be left to the Editor, if we agree.

Overall, I feel very good about this document - very crisp and precise.

 

As a priority, I'd focus on these two that may be more than editorial:

 

[11]

[19]

 

 

Regards,

Jacques

 

 

--------------------------------

Section 1:

 

[1]- def of "association" is not very clear... it seems recursive.

 

[2]- def of Test Case : could include a mention that "Test Cases usually are grouped

in a Test Suite."

 

--------------------------------

Section 3.1:

 

[3]- Informal names for TA parts: qualifying the names with "Test Assertion"

(e.g. Test Assertion Target) seems redundant, and inconsistent: we only do that for

Test Assertion Identifier and Test Assertion Target (why?). Suggest to remove.

 

[4]- Inside the def of Target: suggest to add a "note: a test assertion may concern

more than one [part of] implementation. It is recommended however to select only

one of these as the Target."

 

[5]- Def of Prerequisite: its las sentence is a repeat (said before).

 

[6]- Def of "Tag":

- remove the (s)

- remove the references to the reader

("these tags provide you with..." --> "these tags provide an opportunity...")

("they enable you to group..." --> "they allow for grouping")

Same for the "Variables" definition --> Variable.

 

--------------------------------

Section 3.2:

 

[7]- same as [3], for the names in the table.

 

[8]- in the testAssertion formal def: paragraph before last: it seems to suggest that

several prerequisites are OK ("... together or multiple prerequisites...

A test assertion may have prerequisite(s)". Remove these allusions.

Confusing as we clearly have just one Prereq.

 

[9]- Formatting: each new construct that is introduced as : "Formal Definition:"

is not highlighted enough: only the root constructs are, e.g. normativeSource.

I wish its parts would also be highlighted in some way, e.g.:

Formal Definition for refSourceItem:", or with a title, even if at same

level as normativeSource (for refSourceItem, derivedSourceItem...)

 

[10]- when introducing textSourceItem and derivedSourceItem: it is said they

are "alternatives" to other options, suggesting exclusiveness.

Make it clear they could be "an alternative - or a complement - to.."

 

[11]- derivedSourceItem: why does it have a complex structure like refSourceItem?

Should be much simpler like textSourceItem.

 

[12]- definition of "interpretation":

We could add: "It provides additional clues about how the Predicate (or Prereqisite)

relates to the normative source."

 

[13]- Target def: "The Target shall be the subject of the test assertion..."

Because of [4] above, say rather: "The Target shall be the primary subject of

the test assertion.."

 

[14]- def of Variable:

replace:

"...using a notation such as $variable1"

with:

"...e.g. using a notation such as $variable1"

Also, add that " a variable may also contain a logical expression, e.g. a subset

of a Prrequisite or Predicate."

 

[15]- def of Report:

Replace:

"the circumstances which shall be true for the report to be generated. It shall contain an expression

which evaluates to true or false."

with:

"the circumstances in which this report item should be generated. It shall contain an expression

which evaluates to true or false, or refer to such an expression (e.g. as contained in some variable) ."

 

--------------------------------

Section 3.3 (Semantics)

 

[16]- replace:

"As a test assertion has parts that can be evaluated over a Target instance

(i.e. the prerequisite and the predicate),..."

with:

"As a test assertion has parts that can be evaluated over a Target instance

(i.e. the prerequisite, the predicate, and possibly some variable containing expressions),..."

 

[17]- use bold font for the semantic outcomes ("Target not qualified", etc)

 

--------------------------------

Section 4:

 

[18]- as a gneral rule, there should be a short introductory sentence between the sub-Titles and the

formal def of the construct they announce:

E.g. below testAssertionSet and its formal def, add:

"Test Asserions may be grouped using a testAssertionSet class."

- Same for testAssertionRef: move up the sentence :

"A test assertion set may refer to one or more test assertions by their test assertion identifiers rather than

include the test assertions literally within the set."

- Same for testAssertionResource:

"testAssertionResource is used when test assertions are contained in another external document."

 

--------------------------------

Section 5:

 

[19]- Conformance clause:

- in (2) and especially (3): should we replace "test assertion parts" with "test assertion constructs",

because in section 4 these are not TA parts per say, but more generally higher level constructs as well.

- Should we also consider a second kind of conformance target, beside "representations":

By extension, instances of Test Assertions can be said conforming to this model, if:

- if they use a "TA representation" that is itself conforming.

- or even if they use a simple informal notation not defined by a formal representation, they must use this

notation in a way that is unambiguously mapped to this model and its class system, e.g. respecting

cardinalities and using unambiguous names.

(I am thinking of the informal notation we introduce in the Guidelines, for examples...)