Re: [tag] Some issues on current draft

[stephen.green@systml.co.uk]

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