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

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

Hi Kevin

Yes, I'm OK with deleting 3.7.1 - Visibility. I think it might be that this
is covered in my revision of 3.7.2, though of course I anticipate you might
want to amend my 3.7.2 revision iteration.
In paragraph #2 of 3.7.2 I have
"An alternative, if no such test assertions for the referenced
specification exist,..."
which very briefly covers visibility.

Sorry, my latest iteration crossed in the post with yours so I didn't
include this
deletion of 3.7.1 on Visibility

Best regards

Steve

2009/1/8 Kevin Looney <Kevin.T.Looney@sun.com>:
> 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:
>
> 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)."
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------- To
> unsubscribe from this mail list, you must leave the OASIS TC that generates
> this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



-- 
Stephen D. Green

Document Engineering Services Ltd



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