[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Handling of "multi-target" TAs
I guess maybe that should be "[the distances between the blue and red and between the black and red buttons] are equal" (unless the buttons are arranged in a triangle, which doesn't appear to be the case from the original predicate) 2010/1/25 Stephen Green <stephen.green@documentengineeringservices.com>: > One last try on this. > > How about a predicate with three subjects: > > "the blue button, the black button and the red button are equidistant" > > Here each button is an object which could equally be a target but we > would say the target is the distances between the buttons > > "[the distances between the red, blue and black buttons] are equal" > > so the 'relationships' between the objects (distances) become the > target (and maybe this is not really a combination target as such) > > > Best regards > > Steve > --- > Stephen D Green > > > > > 2010/1/25 Stephen Green <stephen.green@documentengineeringservices.com>: >> OK, thanks >> >> Steve >> >> >> >> >> 2010/1/25 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 >>>>> >>>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]