[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Handling of "multi-target" TAs
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]