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