Re: [tag] Comment on mark-up: overriding rules between TA and set Header

[Stephen Green <stephen.green@documentengineeringservices.com>]

Jacques

I accept that the logical expressiveness requires something like your suggestion
but maybe usability requires something less expressive but easier to understand

and to implement when there is potentially unlimited nesting allowed. Maybe the
two sets of requirements - expressive power on one hand and usability on the
other - are in tension to some extent and we need a compromise, perhaps

in favour of usability since the users are not likely to be experts in logic so much
as experts in the spec or in testing. I guess we need more feedback on this one.
I like the suggestion though.
---

Stephen D Green

2009/8/5 Jacques R. Durand <JDurand@us.fujitsu.com>

Stephen:

 

 

In the mark-up (5.2) you give two different "conflict resolution" semantics, when a TA part is specified both inside the TA and in the TA set header :

 

For a Predicate, the TA part simply overrides the Header part:

"A predicate element contained within a header element of a testAssertionSet MUST be treated as the predicate to each testAssertion contained in the testAssertionSet unless the testAssertion itself contains a predicate. "

But for a Prerequisite, it seems that the  TA part COMPOSES with the Header part:

"A prerequisite element contained within a header element of a testAssertionSet MUST be treated as a prerequisite to each testAssertion contained in the testAssertionSet in addition to any prerequisite already contained by a test assertion within the test assertion set."

Not sure we can justify this difference in overriding policies:

- both Predicate and Prerequisite are logical expressions. It is quite possible in some cases we want the Predicate part specified in the Header, to COMPOSE as well with the Predicate inside the TA (i.e. we want every TA of the group to fail on the same predicate subset).

- Or conversely, we may want an overriding policy for the Prereqisites: e.g. for most TAs in the group, Prereq TA123 applies. But for a few, we want a specific TA (that may or may not subsume the test that TA123 is doing).

Plus, a Prereq could compose in an OR way, e.g. the individual TA prereq may define an alternative to the "standard" prereq from the Header (either one must be satisfied).

Suggestion:

- for each "TA part" defined in the header, we add a "@conflict" attribute that specifies how to handle conflicts:

either @conflict="override", or @conflict="compose-and" or @conflict="compose-or".

 

-jacques