Re: [tag] Re: Proposed shorter text for 3.7.2 Composition of Assertions

["Stephen Green" <stephen.green@documentengineeringservices.com>]

Thanks Kevin

I'll probably go back to the original and start from there
with your proposals; then'll see if anything else seems
appropriate to change too, in line with those changes.

Best regards

Steve

2009/1/8 Kevin Looney <Kevin.T.Looney@sun.com>:
> Hi Stephen,
>
> Here are some comments from your last edit (and merging some of the previous
> comments from Jacques/me).
>
> Thanks,
> Kevin L
>
> ________________________________
>
> ([KL]Stephen, we should probably look back and edit the intro to 3.7.  If we
> remove the section on visibility, then we can probably remove the breakdown
> description of the following subsections. )
>
>   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:
>
> ([KL]Jacques revised the example - introducing normative statement, and
> identified requirement.)
>
> Case 1: The Widget specification says: "All requirements in this section
> only apply to "mini" widgets, i.e. widgets
> that are conforming to the Mini-Widget Small Box specification 1.2."
>
> "Requirement 701: If  a mini-widget has a battery holder, then the
> mini-widget MUST be labelled as 'low voltage'."
>
>
> TA id: widget-TA701
> Target:  Widget
> Normative Source: Requirement 701 of the WidgetSpec 1.0
> Predicate: [the widget] is labelled 'low voltage'.
> Prescription Level: mandatory
> Prerequisite: [the widget] is conformant to the Mini-Widget Small Box
> Specification 1.2 AND  [the widget] has a battery holder.
>
> Scope of Inclusions
>
> An umbrella specification usually relates to a referenced
> specification by assuming or requiring conformance of its
> implementation to this specification. [KL]These conformance relationships
> may be expressed in either the predicate or the prerequisite of a TA.
> Variations exist as follows.
>
> ([KL]reduced to two variations.)
>
> conformance to an (entire) umbrella specification, or specification profile
> conformance to a specific normative statement from the umbrella
> specification
>
> The predicate or the list of external test assertion references
> would reflect such variations.
>
> ([KL]I think this statement is meant to replace the descriptions of how one
> might express conformance (in either predicate or prerequisite) to either
> (a) whole/part of a referenced spec, (b)single normative statements in a
> referenced spec.  The section is definitely 'more terse' without the
> enumeration of these variations.  Is it 'too far' without the examples?
> Perhaps TA701 shows a proper example (eg. Conformance expressed in the
> prereq to a (entire) referenced spec)?)
>
> 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.
>
> ([KL]Jacques and I considered rewording this (perhaps orthogonally).  I
> think more emphasis should be placed on how 'referenced specs' have profiles
> with various statements of inclusion/optionality. The conditionality applies
> to 'overriding the optionality of the profile'.
>
> The key is that 'when an umbrella spec references these profiles, it may
> specify a change to this inclusion/optionality in a prerequisite in various
> ways (mandatory -> optional, optional -> mandatory, optional/mandatory
> (based on other conditions)).
>
> ([KL] I also wonder whether this section is too terse without an example.)
>
> 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).
>
> ([KL] This section remains at a sufficient level of description.)
>
>
> ([KL] Jacques has claimed this new dimension, we haven't really discussed it
> much.
>
> Jacques description:)
>
> For example, Spec B is a
> specialized form of Spec A. Here, spec A is most general spec, and spec B is
> adding to it (e.g. like a WS-* spec is adding to or building on top of SOAP
> spec). So here, B is often requiring full conformance
> to A.
>
> and it looks like Stephen introduced this in 3.7 intro:
>
> Specification modularity may also come from a "prototypical specification" -
> a "base specification" - from which specialized derivative specifications
> may define specific information for a given context.
>
>
> ([KL] Upon further thought, I'm wondering if this is a dimension, if it is a
> sub-case of "Modification", or maybe just something different.
>
> Consider this as a sub-case of Modification:  With the addition of more
> assertions to a specification, we are typically 'strengthening' the
> specification (in a similar way to modifying individual assertions to
> strengthen requirements).
>
>   Jacques, if you agree with this view, perhaps we can simply mention in the
> modification section that 'a referenced specification may be modified
> through the addition of further requirements'.)
>
>
>
>
>
>
> ________________________________
>
>
> Stephen Green wrote:
>
> "  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)."
>
>
>
>
>
>
>
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice