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: RE: [tag-comment] Minor items on thetestassertionsmodel-1.0-cs-01.pdf



See my quick personal answers inline <JD> .

To be finalized in coming TAG TC meeting, next Tuesday.





From: Eric Johnson [mailto:eric@tibco.com]
Sent: Friday, February 18, 2011 9:44 AM
To: tag-comment@lists.oasis-open.org
Subject: [tag-comment] Minor items on the testassertionsmodel-1.0-cs-01.pdf


The SCA Assembly TC was asked to consider endorsing this model, which got me looking at it.

Then, a separate question came up in the SCA Bindings TC, which led to this:

1) Normative reference item

Normative reference to the ISO/IEC directives was new to me, so I wanted to track them down, but there's no link from this spec.

At a minimum, this should link to the organization from which I am expected to get this document, but it appears that I can retrieve the document from one of the following:




Link, please?

<JD> Your last link will be added in coming  upgrade of specification.

2) Question on conformance

The question that came up in the bindings TC - is a test assertions document itself expected to have a conformance statement? That is, our TC has produced a test assertions document, but as it happens, we didn't put in a conformance statement (and are considering releasing it as simply a "note").

Would this be consistent with the model? I did a quick scan of the document, and could not tell.

<JD> Of course it is OK... When you write a test assertions doc for your specification, there are two different kinds of conformance not to be confused, but only one is subject to “conformance clauses” in your document.  Conformance of your TAs to the TAG  model is not subject to any conformance clause in your document – at best you should refer to the TAG “TA model” specification and state that your TA design is complying with (or following)  the TAG model, but there is no need for a formal conformance clause (since your doc is in the position of being an *implementation* of TAG work anyway). If you ever have something like a Conformance Clause in a test assertions doc, the conformance target would be a Test Suite implementing these TAs, or even a test engine as well. A conformance clause would look like:

“A test suite is conforming to this set of test assertions for spec XYZ, if it has test cases implementing at least the subset {a,b,c,d,…} of these TAs, and if each test case – when executed on an implementation of XYZ - is producing an output that is in accordance with the intended semantics of the related test assertion (meaning the output should indicate the target is ”not-qualified” if the pre-requisite fails (if any), should indicate “success/pass” if Predicate is true and Prerequiste also if any, should indicate “failure” if Predicate is false and Prerequiste = true if any.) NOTE: you might also define additional things for a TA that extend the TAG model, e.g. add error messages to your TAs, and require in the conf clause that a conforming test suite reuses these error messages.


3) Conformance section

Section five of the document references other parts of the document, but does not hyperlink to said parts. Makes the document harder to use (example "the TA model (Core TA parts)" - not actually the title of that section! My initial attempt to understand this reference by doing a "Copy" + "Find" failed.)

Other specifications that I've worked on at OASIS collect the normative assertions in a cross-linked table. Conformance section is then simply identifying which tables apply to which conformance targets. I find that quite useful.

It is also quite useful to name the conformance targets. So then the normative text can say "a test assertion language shall ...).


<JD> We’ll take that comment into account for coming release. In fact we were already considering naming the conformance targets.

4) Introduction

Introduction uses bolded shall, however nothing in the conformance section references section 1 as being part of a conformance target. I also note that these assertions in the introduction appear to repeat in section 3.2.


<JD> I think you are right – it looks like the use of these keywords is “abusive” in the Introduction – we will discuss this in TC but I think they should just be informal “must/shall”.

5) These same assertions noted in #4

"These are terms familiar in an object oriented paradigm but shall not be strictly interpreted as object oriented terms."


"The use of the object oriented terminology shall not be taken to mean that the implementation is to be object oriented."

seem to be normative assertions where the conformance target is the reader of the document, and the use of "shall" seems suspect.

<JD> I think you are right – same abusive use of normative keywords, not directly concerning an implementation of the specification.


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