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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Update to section 3.6 (Multiple Specifications)


Hi everyone,

     I updated section 3.6 according to Jacques' recommendations.   The 
text is below, and will appear in the wiki.   Stephen, please feel free 
to tweak any of the text.

Thanks, Regards,
Kevin L

====================================================================================================


3.6 The Case of Multiple Specifications

Modularity and succinct description within specifications can be 
achieved by leveraging existing specifications that are referenced by 
other specifications. Specification writers often create "umbrella 
specifications". These are widely scoped specifications that delegate 
certain normative descriptions to other "referenced specifications".

Specification modularity may also come from /prototypical 
/specification, such as a "base specification", from which specialized 
derivative specifications may define specific information for a given 
context.

For proper specification analysis, inclusion of test assertions from 
both the umbrella (or base) specification and all the referenced 
specifications should be considered.

Two aspects of analysis of multiplicity of the normative sources are 
considered:

    * Specification Visibility (Section 3.6.1) deals with how assertions 
from a referenced specification are considered or described in the 
umbrella specification
    * Composition of Assertions (Section 3.6.2) describes how predicates 
and prerequisites can express various relationships between umbrella and 
referenced specifications

3.6.1 Specification Visibility

Consider a case where a specification is the normative source but it 
itself refers normatively to a second specification. Consider firstly 
the case where there is no visibility of any test assertions covering 
this second specification. Here there may be a prerequisite that all 
test assertions for the second specification be treated as a single 
Boolean requirement.

In a second case the specification refers to a second specification for 
which the test assertions are given visibility and here the test 
assertions of the first specification may refer to individual or groups 
of test assertions of the second specification as explicit 
prerequisites. Of course, any number of normative sources may be 
involved, some with test assertions visible, others not.

3.6.2 Composition of Assertion

There are three dimensions that describe how test assertions for an 
umbrella specification can refer to another specification:

'scope of inclusion',

'conditionality of inclusion',

'modification of inclusions'.

These relationships between specifications can be expressed using a test 
assertion. This form of a test assertion is a specific form of a test 
assertion, as it expresses some form of conformance (like a conformance 
clause).

Multiple dimensions can be expressed within these relationships (for 
example, a subset of test assertions from a reference spec may be 
conditionally used in an umbrella specification).


Scope of Inclusions

An umbrella specification usually relates to a referenced specification 
by assuming or requiring conformance of its implementation to this 
specification.
These conformance requirements can be expressed in a test assertion's 
prerequisite or predicates.

The scope of this conformance may be determined by the expressions in 
these prerequisites or predicates.

The logical expressions used in the predicate may also include a 
conformance requirement for varying scopes of the (current) umbrella 
specification 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

Similarly, the logical expressions used in a prerequisite may also 
include a conformance requirement for varying scopes of the external 
specification as follows:

    * conformance to an (entire) referenced specification
    * conformance to a profile of an referenced specification
    * conformance to a specific test assertion from an referenced 
specification

A simple example might be a wholesale inclusion that describes where a 
target in an derivative specification is completely conformant to the 
assertions of a base specification.

    *

      TA id: widget-TA100-8

      Target: Widget

      Normative Source: Conformance clause of WidgetSpec 1.0

      Prerequisite: [the widget] is conformant to Mini-Widget Small Box 
Specification 1.2

      Predicate: [the widget] is conformant to WidgetSpec 1.0

      Prescription Level: mandatory

    *

Interpretation: "A  widget that conforms to the Mini-Widget Small Box 
Specification 1.2.  must be conformant to the WidgetSpec 1.0 specification."

Another example might be a partial inclusion that describes a case where 
a target in an umbrella specification is conformant to some subset of 
assertions in a referenced specification. Subsets of a specification are 
described as 'Conformance Profiles', and may be expressed via grouping 
constructs (using 'lists'):

 
            TA id: widget-TA100-9

            Target: Widget

            Normative Source: WidgetSpec 1.0

            Prerequisite: [the widget] is conformant to the "smaller 
box" Conformance Profile of the Mini-Widget Small Box Specification 1.2.

            Predicate: [the widget] is conformant to WidgetSpec 1.0

            Prescription Level: mandatory

Note: "Some portion of the TAs for the Mini-Widget Small Box 
Specification 1.2 are identified in a list to indicate their inclusion 
in the Smaller Box conformance profile"

Interpretation: "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"

Conditionality of Inclusions

This dimension of inclusion describes the conditionality whether 
assertions in an umbrella specification is conformant to a referenced 
specification. 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 be optional

The example of widget-TA100-8 already shows how a widget describes 
mandatory conformance. The following widget describes a conditional 
conformance:

    *

      TA id: widget-TA100-10

      Target: Widget

      Normative Source: specification requirement 120 in WidgetSpec 1.0

      Prerequisite: IF [the widget] has restriction of box size 760 mm x 
480 mm x 100 mm or less THEN [the widget] is conformant to the 
Conformance Profile of the Mini-Widget Small Box Specification 1.2.

      Predicate: [the widget] is conformant to WidgetSpec 1.0

      Prescription Level: mandatory

Interpretation: "All widgets conformant to the WidgetSpec1.0 
specification must also be conformant to the assertions of the 
WidgetMobile Small Box Specification 1.2 IF the widget is smaller (or 
equal) in size to 760 mm x 480 mm x 100 mm "

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 assumes some partitioning of the 
unchanged assertions and modified assertions. You can use "lists of 
assertions" to describe in the pre-requisite the subset of assertions 
that the umbrella specification is conformant to "unchanged". The 
remaining test assertions (changed set) can be individually specified as 
test assertions of the umbrella specification.

Typically, assertions are modified in a referenced specification to 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).


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