[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Some glossary notes based on F2F talks
My $0.02 inline <JD>.
Jacques From: Lynne Rosenthal [mailto:lsr@nist.gov] Sent: Thursday, December 20, 2007 11:59 AM To: Durand, Jacques R.; TAG TC 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
<JD> sounds good to
me. 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.
<JD> Conformance Clause : Does it have to be part of the specification? How about: Set of statements referring to the normative material of a specification, and that defines the requirements, criteria, or conditions to be satisfied in order to claim conformance to this specification. (should we mention the possibility to address some specific profile?) 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]