RE: Handling of "multi-target" TAs

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

 Stephen:
inline

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Monday, January 25, 2010 4:59 AM
To: Jacques R. Durand
Cc: TAG TC
Subject: Re: Handling of "multi-target" TAs

Looking again at

> "In cases where the predicate of a test assertion needs to use more
> than one object (part of an implementation), it is possible to
> consider their composition as the target. However in many cases, one
> of them must be selected as the target, while the other objects are
> accessory to the test. Such objects can be referenced in the predicate
> or prerequisite using variables."

Is there a way we can improve these statements as normative statements, appropriate for the model spec?

Firstly, as before we may need to tighten our semantics for 'target', 'object' and 'accessory object'. Maybe we do not need to state these semantics, just to be clear about them as background to the statements we make (?).

<JD> How about:

"The predicate may express a condition over more than one object. These objects are either parts of an implementation or external resources. A unique target object is still required by this model. In such a case, either the target is defined as the combination of objects that are expected to satisfy the predicate, or one of these objects may be selected as the target while the other objects are just considered as accessory to the test. Such objects may be referenced in the predicate or prerequisite using variables."

Secondly we are presenting a choice for how a target relates to a test assertion and to a predicate in particular: Can we improve the two normative statements to this effect? In the second case/choice of approach we offer we have the word 'can' which maybe we need to replace with a normative term such as 'may':

<JD> Right.

"However in many cases, one of them must be selected as the target, while the other objects are accessory to the test. When there is a requirement to select a single object as a target from several objects, the other, accessory objects <b>may</b> be referenced in the predicate or prerequisite using variables."

Likewise for the first statement

"In cases where the predicate of a test assertion needs to use more than one object (part of an implementation), their composition <b>may</b> be treated as the target."

Then the second statement would follow as:

"However in many cases, just one of several objects must be selected as the target, while the other objects are accessory to the test. When there is a requirement to select a single object as a target from several objects, the other, accessory objects <b>may</b> be referenced in the predicate or prerequisite using variables."

I would tend to add:

"Alternatively, the relationship between the objects <b>may</b> itself be treated as a single target."

<JD> I am afraid that this could be confusing: a "relationship" is often understood as just the link between two objects, or the property that relates them together: here, the "widget ID" can be seen as this link - yet the predicate looks at more data than the link data. Isn't a "combination of objects" more intuitive, even if less formal?.

 

Best regards

Steve
---
Stephen D Green




2010/1/24 Stephen Green <stephen.green@documentengineeringservices.com>:
>>
>> "In cases where the predicate of a test assertion needs to use more
>> than one object (part of an implementation), it is possible to
>> consider their composition as the target. However in many cases, one
>> of them must be selected as the target, while the other objects are
>> accessory to the test. Such objects can be referenced in the
>> predicate or prerequisite using variables."
>
> I agree, provided the 'must' in "one of them must be" is not a
> normative MUST since there are alternatives (as considering "the
> composition as the target" or, in my example just posted, considering
> the relationship between two or more objects as the target).
>
> I do wonder whether we have defined clearly what a 'target'
> actually is - the rationale / reason for having one object in a
> predicate distinguished and called a 'target'. We have done so
> implicitly (something in an implementation which is a focus for
> testing and/or subject of the assertion, though I'm not sure we are
> clear whether test target or assertion subject is the primary focus).
> Should/could this be more explicit. Why, exactly, explicitly, does a
> particular object in a predicate/assertion need to be (and qualify for
> being) denoted a 'target'?
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/23 Jacques R. Durand <JDurand@us.fujitsu.com>:
>> Stephen:
>>
>> Looks good to me except for the handling of "multi-target" Tas:
>>
>> In TA model you add:
>>
>> "In cases where more than one target is relevant to a test assertion,
>> additional targets may be treated as accessory objects and reference
>> to these made using variables (see variables section below) and
>> combined to form a compound target expression."
>>
>> I think the following updates are needed:
>> - we need to be more assertive  on what is to be done (may -> must :
>> the user does not have the choice !)
>> - also explain a bit more the "multi-target" situation, while
>> avoiding to call the additional objects "targets"
>> - and finally, the target of such a TA is in general NOT the compound
>> of these objects (though it may):
>>
>> "In cases where the predicate of a test assertion needs to use more
>> than one object (part of an implementation), it is possible to
>> consider their composition as the target. However in many cases, one
>> of them must be selected as the target, while the other objects are
>> accessory to the test. Such objects can be referenced in the
>> predicate or prerequisite using variables."
>>
>> I suggest we add a similar note in the Guidelines, a little more
>> verbose with a little inline example, say at the end of 4.1 "Complex
>> Predicates", since this issue is normally coming up when people have
>> to define a predicate using several obejcts:
>>
>> "Another case where a predicate is more complex is when its
>> conditional expression involves more than one part of an
>> implementation(s). In some cases it is clear which one of these
>> objects must be considered as the target, while others are just accessory objects.
>> Consider the following predicate: "the [widget price tag] is matching
>> the price assigned to this widget in its [catalog entry]", where
>> price tags and catalog entries are both items that must follow the
>> store policy (the specification). In that case it may be reasonably
>> assumed that the "catalog" content is authoritative over the price
>> tag. The price tag can then be considered as the test target, while
>> the accessory object may be identified by a variable which is then
>> used in the predicate.
>>
>> Other cases are more ambiguous.
>> Consider the following predicate: "the [widget price tag] is matching
>> the price that is reported on the related [item in promotion list] at
>> the store entrance", where it is not clear at which one of these
>> often-changing labels must be incriminated in case of discrepancy
>> (although whichever is lower will likely prevail should a customer
>> complain).
>>
>> Three approaches are possible:
>>
>> (1) Consider a combined target, here a pair [price tag and promotion
>> item for widget X] that is identified by the widget ref number. This
>> combination will fail or pass the test.
>> (2) Select arbitrarily one object as the target, while the other will
>> be accessory, e.g. identified by a variable. In a derived test case,
>> a predicate failure will inevitably lead to examine both, should the
>> accessory object be causing the failure.
>> (3) Write two similar test assertions using alternately one object
>> and the other as targets."
>>
>> For review...
>>
>> Jacques
>>
>>
>> -----Original Message-----
>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On
>> Behalf Of Stephen Green
>> Sent: Friday, January 22, 2010 11:56 AM
>> To: TAG TC
>> Subject: [tag] Further iteration (any more changes/discussion?)
>>
>> Now we do seem to be nearing drafts we can vote on:
>>
>> Model:
>> http://www.oasis-open.org/committees/document.php?document_id=36047
>> http://www.oasis-open.org/committees/download.php/36047/testassertion
>> smo
>> del-draft-1-0-4.pdf
>>
>> Markup:
>> http://www.oasis-open.org/committees/document.php?document_id=36048
>> http://www.oasis-open.org/committees/download.php/36048/testassertion
>> mar
>> kuplanguage-draft-1-0-5.pdf
>>
>> Guidelines:
>> http://www.oasis-open.org/committees/document.php?document_id=36049
>> http://www.oasis-open.org/committees/download.php/36049/testassertion
>> sgu
>> idelines-draft-1-0-9-6.pdf
>>
>> If you just want to see the diffs from previous internal review
>>
>> http://www.oasis-open.org/committees/download.php/36043/testassertion
>> smo
>> del-draft-1-0-4-changes.pdf
>> http://www.oasis-open.org/committees/download.php/36042/testassertion
>> mar
>> kuplanguage-draft-1-0-5-changes.pdf
>> http://www.oasis-open.org/committees/download.php/36041/testassertion
>> sgu
>> idelines-draft-1-0-9-6-changes.pdf
>>
>> Is there more to discuss? Are there more comments? Can we vote on
>> these drafts?
>>
>> I'm not sure exactly how this works but I think we would have to vote
>> on the editable source (ODT) versions:
>> http://www.oasis-open.org/committees/download.php/36046/testassertion
>> smo
>> del-draft-1-0-4.odt
>> http://www.oasis-open.org/committees/download.php/36045/testassertion
>> mar
>> kuplanguage-draft-1-0-5.odt
>> http://www.oasis-open.org/committees/download.php/36044/testassertion
>> sgu
>> idelines-draft-1-0-9-6.odt
>>
>> and the schema:
>> http://www.oasis-open.org/committees/document.php?document_id=35840&w
>> g_a
>> bbrev=tag
>> http://www.oasis-open.org/committees/download.php/35840/testAssertion
>> Mar
>> kupLanguage-draft-1-0-3.xsd
>>
>> and namespace document:
>> http://www.oasis-open.org/committees/document.php?document_id=35788&w
>> g_a
>> bbrev=tag
>> http://www.oasis-open.org/committees/download.php/35788/namespace.zip
>>
>>
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>> ---------------------------------------------------------------------
>> 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.ph
>> p
>>
>>
>