Some glossary notes based on F2F talks

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

Here is a status of proposed glossary updates based  on F2F discussions and some notes Patrick sent me that I still need to consolidate  (Patrick please correct if  needed).

 

I introduced some additional proposed updates and/or comments at places, see my "notes":

 

-Jacques

 

 

Core Terminology:

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

 

1. Normative Statement, or Normative Requirement:

 

A statement made in the body of a specification that defines prescriptive requirements

for, or prescriptive properties of an implementation.

A normative statement or normative requirement typically uses keywords such as those

defined in IETF RFC2119 or ISO/IEC (MUST, SHOULD, MAY...)

 

Note: maintain the alternative statement/requirement, as requirement alone may appear as

conflicting with optionality (SHOULD/MAY). But when focusing on the implementation,

I have introduced "properties" in case these are not formally required (again due to optional statement)....

"Prescriptive" seems to be the right word: does not imply "required", yet the status of a law / rule potentially enforceable.

 

2. Implementation:

 

product, document, process, or service that is the realization of some normative statements

or requirements of a specification.

 

Note: we did not find any better than "realization"... And also kept the intuitive enumeration

of what it can be, even if not covering all cases. We said an implementation will qualify as a conformance target,

but that etst assertion targets can be more fine-grained.

 

3. Test Assertion:

 

Testable expression derived from normative statements and/or requirements.

Generally applies to an element of an implementation.

A TA describes the expected property or behavior of an implementation element

that fulfills the statement or requirement, in a way that can be measured or tested.

 

Note 1: removed the "specific operation conditions" that we knew needed clarification and was too close

to test metadata. The above wording tries to remain orthogonal to the notion of "requirement"

(in case of optional statement)

 

Note 2: An alternative definition proposed below (see at the end of my email Dec 10th, about

"handling of optional statements")

"A testable expression for evaluating whether or not an implementation (or element of) exhibits a feature or behavior subject

to a normative statement or requirement in the specification."

(I thought the purpose of the TA is more apparent, and the expression "feature or behavior subject to..." introduces more

distance with RFC keywords, avoid confusion of what it means to "fulfill" or "adhere" to a SHOULD/MAY statement.)

 

 

4. Test Assertion Target (formerly knows as IUT)

 

Implementation or element of an implementation that is the primary subject of a test assertion,

i.e. the element about which a decision will need be made concerning its adhesion to the specification.

The target is generally defined as a class of such elements to which the TA applies.

 

Note: I introduced the term "primary subject" and what it means, because there might be other collateral

implementation elements used in the TA predicate (see WS-I) so we need to disambiguate.

 

 

Non-Core Terminology:

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

 

5. Test Case

 

Consists of a set of a test tool(s), software or files (data, programs, scripts, or instructions

for manual operations) that verifies the adhesion of an implementation or implementation element

to one or more normative statements in the specification.

Typically, a Test Case is derived from one or more Test Assertions.

 

6. Conformance (need rewording)

 

Satisfies some or all (can't use all). How to distinguish this use of the term conformance

and the notion of conformance clause.

Term by itself implies that all requirements are met. However, in the absence of a formal

mechanism for specifying "partial conformance" (eg the definition of modules, levels)

the term can still be usefully qualified by applying "partial".

Fulfilment of requirements by an implementation. ??? come back to this...

Conformance clause should be listed first.

 

======

 

Take the OASIS definitions for conformance, conformance clause, conformance claim, conformance target

Clarify the difference between a conformance clause and a test assertion?

Test assertion is low level (finer granularity targets)

Conformance clause is much higher level (conformance target is an entity that has some significance

from a user viewpoint and certification viewpoint).

Often, but not necessarily, makes reference to a set of test assertions.