OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tag] Some glossary notes based on F2F talks


Sorry for not getting to this sooner.  Comments are in-line

n       regards, Lynne

n        

 

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...)

 

[lsr] Is there a reason for saying “in the body of a specification”?  That seems to imply that normative statements can not appear in an Appendix.  It is not-a typical to have a Normative Appendix.  Why not delete “in the body”.

 

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.

 

[lsr] suggest rewording:  Testable or measurable expression

 

Generally applies to an element of an implementation.

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

 

[lsr] add “action” à  “expected property, action or behavior”

 

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)

 

 

[lsr]  Suggest: Conformance = The fulfillment of a product, process, or service of specified requirements.

Conformance Clause = Section of a specification that defines the requirements, criteria, or conditions to be satisfied in order to claim conformance.

 

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.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]