Re: [tag] Current issue with "TA for properties"

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

And maybe the only thing we haven't done is to mention
the additonal use we found for variables when writing our
markup - as ways to extend the expressiveness of other
expressions in targets, prerequisites and predicates by
associating sub-expressions with variables in a set
header or in the test assertion itself.

Maybe it is too early in our test assertion markup work to
feed back such details into the guidelines though.

Best regards

Steve

2009/5/21 Stephen Green <stephen.green@documentengineeringservices.com>:
> Done.
>
> see http://www.oasis-open.org/committees/download.php/32623/TestAssertionsGuidelines-draft-1-0-4.pdf
> for PDF version
>
> 2009/5/21 Stephen Green <stephen.green@documentengineeringservices.com>:
>> Plus I made some further editorial changes to the section on
>> grouping using tags to make it fit with this prior section which
>> now introduces tags a little in advance.
>>
>> I will upload this work as draft 1.0.4
>>
>> Best
>>
>> Steve
>>
>> 2009/5/21 Stephen Green <stephen.green@documentengineeringservices.com>:
>>> I've edited the section on property test assertions so that it now
>>> reads as follows:
>>>
>>>
>>>
>>> Test Assertions for Properties
>>>
>>> Requirements addressed by test assertions may be related to specific
>>> properties of a target. Assume there are specification requirements
>>> that define under which conditions a widget qualifies as
>>> “medium-size”. In other words, widgets do not come with a sticker that
>>> makes this categorization obvious by announcing small / medium /
>>> large. Instead, the size label is a property that is itself defined in
>>> the widget specification and that is subject to verification, like any
>>> other normative statement. In such a case, when writing test
>>> assertions, it is not a good idea to consider this property as part of
>>> the definition of the target category as in the case widget-TA101-1a
>>> and widget-TA101-1b, because the category of a widget could not be
>>> identified prior to doing any test on this widget.
>>> Assume that the following requirement defines the “medium-size” property:
>>> [requirement 104] “A widget that weighs between 100g and 300g and is
>>> from 5 to 15 centimeters long in its longer dimension, is a
>>> medium-size widget.”
>>>
>>> There is a major distinction between requirement 104 and requirement 101:
>>> requirement 101 uses “medium-size” as a prerequisite: its predicates
>>> only concern widgets that are already established as medium-size.
>>> requirement 104 defines how to qualify a test assertion as medium-sized.
>>>
>>> The test assertions for requirement 104 can be written as:
>>>
>>> TA id: widget-TA104-1
>>> Normative Source: specification requirement 104
>>> Target: widget
>>> Predicate: [the widget] weighs between 100g and 300g.
>>> Prescription Level: mandatory
>>> Tag:normative_property = medium-sized
>>>
>>> A tag, “normative_property = medium-sized” is assigned to convey that
>>> the test assertion evaluation relates to the property ("medium-size").
>>>
>>> TA id: widget-TA104-2
>>> Normative Source: specification requirement 104
>>> Target: widget
>>> Predicate: [the widget] is from 5 to 15 centimeters long in its longer
>>> dimension.
>>> Prescription Level: mandatory
>>> Tag:normative_property = medium-sized
>>>
>>> The test assertions widget-TA104-1 and widget-TA104-2 will be used to
>>> derive test cases that verify if the property "medium-size" applies to
>>> some widget. A "false" outcome for their predicates is an indicator
>>> that the medium-size property does not apply. It is not indicative of
>>> a violation of the specification itself. Such test assertions are
>>> called in this document "Property test assertions" to distinguish them
>>> from test assertions that are used as indicators of conformance to a
>>> specification. However, both types of test assertions are designed in
>>> the same way, with a predicate that indicates whether or not a target
>>> satisfies some feature or property.
>>> There is no mention of the “medium-size” property in the predicates of
>>> test assertions ‘widget-TA104-1’ and ‘widget-TA104-2’. This is because
>>> this property is precisely what needs to be established by a test
>>> suite containing test cases that are derived from these test
>>> assertions. Only when a target (here a widget) evaluates to “true” for
>>> these two test assertions, will it be considered medium-size. These
>>> test assertions are only concerned with the nature of these tests, not
>>> with how to interpret their outcome.
>>>
>>>
>>>
>>>
>>> 2009/5/21 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>>> Stephen:
>>>>
>>>> I was indeed the one most in favor of doing this prefixing of the prescription level :-\
>>>> Realized that this does not work in general...
>>>> The tag appears to be the most flexible way: adding a new TA element might open a new can of worms.
>>>> I believe actually that it is good to not relate tightly the prescription level to the "intent" of the TA (here a property), which may change or may be more relevant to a combination of Tas.
>>>> Let us discuss this next week.
>>>>
>>>> Jacques
>>>>
>>>> -----Original Message-----
>>>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
>>>> Sent: Wednesday, May 20, 2009 12:21 PM
>>>> To: TAG TC
>>>> Subject: Re: [tag] Current issue with "TA for properties"
>>>>
>>>> I've not been quite convinced that there was a clear case for putting the property definition in the prescription level. I'm still a little uncertain about merely using a tag but it seems better than overloading presription level so unless anyone objects I will include this in another draft (along with some very minor rewording Jacques has suggested offlist).
>>>>
>>>> Best
>>>>
>>>> Steve
>>>>
>>>> 2009/5/20 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>>>> A medium technical issue with the current TAG draft:
>>>>>
>>>>> In section 3.3 "TA  for Properties":
>>>>>
>>>>> We recommend to mention the property ("medium-sized" ) in the
>>>>> Prescription
>>>>> element:
>>>>>
>>>>>
>>>>> Prescription Level: medium-sized:mandatory
>>>>>
>>>>>
>>>>> Because we want the prescription level to be associated with the
>>>>> definition of this property.
>>>>>
>>>>>
>>>>> [requirement 104] "A widget that weighs between 100g and 300g and is
>>>>> from 5 to 15 centimeters long in its longer dimension, is a medium-size widget."
>>>>>
>>>>>
>>>>>
>>>>> Suggestion: instead of this, use a tag for expressing the association
>>>>> of the TA to the property:
>>>>>
>>>>>
>>>>> Prescription Level: mandatory
>>>>>
>>>>> Tag: normative_property = medium-sized
>>>>>
>>>>>
>>>>> Rationale:
>>>>>
>>>>> - very close association between the Property and the Prescription
>>>>> level (as currently suggested) is a bad idea: it seems to suggest that
>>>>> the TA "widget-TA104-1" MUST evaluate to true (mandatory) for the
>>>>> property to be verified.
>>>>>
>>>>> But that does not work if  [requirement 104] has "or" instead of "and" :
>>>>>
>>>>> [requirement 104] "A widget that weighs between 100g and 300g OR is
>>>>> from 5 to 15 centimeters long in its longer dimension, is a medium-size widget."
>>>>>
>>>>> In that case we only want to indicate that the two TAs involved are
>>>>> related to the definition of this property, nothing more, as you could
>>>>> still satisfy the property even if you fail either TA. The
>>>>> Prescription level should only reflect the wording in the requirement,
>>>>> not be interpreted as a conformance statement.
>>>>>
>>>>>
>>>>>
>>>>> - a "normative property" should ultimately not be treated differently
>>>>> from a conformance profile. In both cases we don't want the
>>>>> Prescription level to be too closely associated with the profile or
>>>>> property (which may require a more complex combination of TAs, to be
>>>>> verified). Using a Tag is more appropriate for such a loose
>>>>> association, whcih has simply the value of an annotation (grouping) with no other formal semantics.
>>>>>
>>>>> - The TA could be associated with several properties.
>>>>>
>>>>>
>>>>>
>>>>> Jacques
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>
>>
>