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


Help: OASIS Mailing Lists Help | MarkMail Help

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

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

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