tag-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Comment on TA Model: need to broaden definition of conforming implementation
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: "TAG TC List" <tag@lists.oasis-open.org>
- Date: Tue, 27 Apr 2010 17:01:42 -0700
Issue:
---------
an implementation of
the TA Model specification is currently too narrowly defined in the
conformance clause : "a representation of the test assertion model" itself
(i.e. a language or notation such as a markup language). That excludes
actual sets of test assertions that are modeled based on this specification, and
that may even not use a formal language. Users such as SCA TC who have written
entire sets of TAs after the TAG model, should be able to provide a successful
"statement of use" as required in the standardization
process.
Proposal:
-------------
The
conformance clause need to broaden the definition of a conforming
implementation:
Two classes of
implementations of the model could be defined (instead of just one
(1)):
(1) languages or
notations that represent the test assertion model described in
Section 3 and Section
4,
(2) actual instances
of test assertions that follow the modeling principles and semantics described
in Section 3 (and Section
4).
For (1), we already
define a precise set of requirements in the conf clause:
(a) shall contain all test assertion parts
defined in Section 3
(b) may contain any test assertion
constructs defined in Section 4
(c) shall use names for these parts that
are identical or can be unambiguously mapped to the definitions
used in Section 3 and implemented
parts of Section 4
(d) shall implement the normative
statements for the test assertion model and its semantics in this
specification.
For (2) the following could be
stated:
A set of test assertions will conform to the
TA model if:
(a) they are represented using a notation or
language that maps
unambiguously to the TA model defined in Section 3,
(b) each test assertion includes
the test assertion parts mandated by the TA model (Core TA
parts)
(c) the parts of each test assertion are
used in a way that is consistent with the test assertion semantics stated in the
TA model .
(d) in case some set-level constructs for
grouping test assertions are used that define elements or values that are common
to the set of test assertions as allowed by the model construct "shared"
(Section 4), or that use some referential scheme e.g. to refer to external TAs
or subsets of TAs (fulfilling the same function as modeling constructs TestAssertionRef,
TestAssertionSet or TestAssertionSelector), then these constructs must map
unambiguously to their counterparts in the TA model and their
semantics.
notes:
- the TA model is expected to be enhanced
with more explicit semantics, supporting (c) above.
- in (2) it is suggested to only focus on
test assertions, and not require the use of the "test assertion set" construct
of the model, which remains optional. Only if similar functions are used, then
they should be used conssitently with the model (d).
-jacques
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]