[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Some issues on current draft
A further issue like Issue 050: Issue 054: We encourage spec writers to writer TAs; if they do so they may actually write the specification in such a way that TAs are built into it which might mean that a TA doesn't so much reference an spec statement - it might actually *be* the normative statement. In that case the spec ref might be unnecessary so it needs to be clear that in this case it is implicit; in this case, implicitly, Spec Ref = TA Id. -- Stephen D. Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice Quoting "Durand, Jacques R." <JDurand@us.fujitsu.com>: > I submit by email these issues on the current draft, having no current > access to OASIS site. > (will file them on wiki) > > -Jacques > > > Issue 050: > [in Section 1.1] ". In the simplest case, an assertion may simply > consist of text from within the specification." > This is a confusing statement that seems to undermine what we say later > about "mandatory" > components of a TA. > We expand enough later on , on the possibility to define "implicitly" > several parts of a TA, so that the > work of defining a TA can be reduced - in some cases - to just referring > to some spec statement. > But even then, the TA still consists of more than the spec reference - > the implicit parts (e.g. as derived > from a rule) are still part of the TA even if not explicitly defined. > Proposal: remove this statement. > > > Issue 051: > [in Section 1.1] ". Sometimes an assertion is included which is not > testable: it acts as a placeholder to represent a requirement not > considered testable. It should be clear that testing of this assertion > is not expected" > > This is confusing: Assuming "assertion" here means "test assertion", > that conflicts with the 1st sentence of the section 1.1 defines TA as > "...action or condition that can be measured or tested". If there is > some exception case to expand on where a TA is deliberately not > testable, I would not discuss it in the Rationale section (confusing) > but in a mor advanced section. As it stands at the beginning of the > guideline, this statement does not give me any useful information - only > confusion. > > Proposal: remove this statement. > > > > Issue 052: > Title of 2.3 "A More COmpex Case" might need rewording: it should not be > understood as something unusual that goes beyond "simple cases" - it is > just a continuation of basic design principles - only one step further > in difficulty (but still on the very "basic" side - explaining > something everybody will face) > Proposal: replace with something like "Some Simple Design Rules" or the > like. > > > Issue 053: > Section 2.2 "Creating Test Assertions" is an insert that breaks the > flow between 2.1 "What is a Test Assertion" and its follow-up (Section > 2.3) in this tutorial-style progression. > The "Testability" subsection has overlap with other more general > material in the guide. > Proposal: This section (2.2) needs probably to be broken down and > redistributed: It has both some introductory material that should belong > to a prior section (or maybe to a "best practice" insert somewhere > else), and some quite challenging examples that are better off being > addressed later. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]