Hi Stephen,
Thanks for reviewing and shortening.
There were a few proposals that Jack and I were reviewing for
changes to 3.7. For one of these, I felt it was best for you to
comment on (since I think you came up with the original descriptions
for 'visibility').
(quoted from Jacques previous message)
<JD> Replace "We need to mention.."
with "We could mention...".
I was only trying to piggyback on these
examples, the discussion opened in 3.7.1 ., telling that it was OK
instead of having:
Prerequisite: [the widget] is conformant
to the Mini-Widget Small Box Specification 1.2
To have something like:
Prerequisite: [the widget] satisfies the
test assertions: TA_MWSBox1.2_101, TA_MWSBox1.2_102, ... (etc.)
The concern I have with 3.7.1 is that it
is a bit abstract introduced as is (and probably does not deserve a
subsection on its own?), and would prefer to see these ideas introduced
as follow-up to a concrete example.
>
> Then one could make a comment about different levels of
visibility: in
> both above cases, the TAs for Mini-Widget Small Box Specification
> could be "visible", in which case the prerequisites could directly
> refer to these TAs or to a group of these (instead of using a
general
> statement of conformance). So we could get rid of 3.7.1 by making
the
> visibility point part of the use cases (a variant for their TAs).
Hmm - I think this is OK, but I'll defer to Stephen since I think he
originally described the visibility section.
From my understanding, the proposal was to reduce 3.7 by removing
3.7.1, reducing the description of visibility as an observation about
one of the examples. What would you recommend?
Thanks, Regards,
Kevin L
Stephen Green wrote:
92040e120901080442t7bbbe3f9gbc10093906bcc0c@mail.gmail.com"
type="cite">
I've shortened the text still further to take into account the following:
Maybe a predicate can refer to a list of other test assertions as a way to
inlude those other ('foreign') test assertions in the current list of
test assertions.
However, in our XML Test Assertions markup we would probably want to use
a list of references to the foreign test assertions within our TestAssertionSet.
This makes use of a TA to cover whole areas of conformance redundant as
we would use a list of references to the external TAs in the TASet instead.
So propose change/shortening as follows
" 3.7.2 Composition of Assertions
There are three dimensions that describe how assertions from a
referenced specification may be included within an umbrella
specification:
'scope of inclusions',
'conditionality of inclusions',
'modification of inclusions'.
These relationships between specifications can be expressed by
including a set of references in the test assertions document for
the umbrella spec. The references would be to any test assertions
from the referenced specification which are required according to
the conformance clause of the umbrella specification. An alternative,
if no such test assertions for the referenced specification exist, would
be to summarize conformance requirements to the referenced
specification in the form of a test assertion using its predicate:
TA id: widget-TA108-1
Normative Source: [interpretation of conformance clause to WidgetSpec
1.0] "All widgets conformant to the WidgetSpec 1.0 specification must
also be conformant to the 'smaller box' assertions of the WidgetMobile
Small Box Specification 1.2"
Target: widget
Predicate: [widget] Conforms to WidgetMobile Small Box Specification 1.2
Prescription Level: mandatory
Scope of Inclusions
An umbrella specification usually relates to a referenced
specification by assuming or requiring conformance of its
implementation to this specification. Variations exist as
follows.
conformance to an (entire) umbrella specification
conformance to a profile of the umbrella specification
conformance to a specific normative statement from the umbrella specification
The prediacte or the list of external test assertion references
would reflect such variations."
Conditionality of Inclusions
It might be that the conformance or otherwise to a referenced
specification is a condition which is included in another test
assertion as a prerequisite. The prerequisite of the assertion may:
a. require that optional portions of the referenced specification
be implemented in the umbrella,
b. conditionally require optional portions of the referenced
specification be implemented in the umbrella (for example, based on
the presence of hardware or some other such support), or
c. make remaining (required) portions of the referenced
specification optional.
Modification of Inclusions
This dimension of inclusion describes where an umbrella specification
is conformant to a referenced specification, where some subset of
assertions must be modified. This means of inclusion assumes some
partitioning of the unchanged assertions and modified assertions. You
can use "lists of assertions" to describe in the prerequisite the
subset of assertions that the umbrella specification is conformant to
"unchanged". The remaining test assertions (the changed set) can be
individually specified as test assertions of the umbrella
specification.
Typically, assertions are modified in a referenced specification that
can be strengthened in a few ways:
strengthening the prescription level of an assertion (eg. x MAY do y
=> x MUST do y), or
strengthening the meaning of an assertion with additional
requirements (eg. IF x THEN z => IF (x AND y) THEN z)."
|