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

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

Yes, I like the idea that there is a basic rule which
gives relatively simple usability but to then allow
the use of the conflict attribute for those who want
more power at the expense of more complexity. 

---
Stephen D Green

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

Good points. Nesting should not make things complicated.

A midleground could be to go with default rules that could be: the TA part overrides the Header part. Or maybe as you stated, Prerequisites compose.

So regular users have a fixed semantics.

Besides this we could still define an optional @conflict attribute for advanced users...?

 

Jacques

---

From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Wednesday, August 05, 2009 2:22 AM
To: Jacques R. Durand
Cc: tag@lists.oasis-open.org
Subject: Re: [tag] Comment on mark-up: overriding rules between TA and set Header

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